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(54) Data transmission apparatus, system and method, and image processing apparatus 



(57) A host computer logs in an image providing de- 
vice such as a scanner connected by a serial bus, and 
reverses flow control of data transfer by issuing a Re- 
verse command. The image providing device opens a 
transfer channel by an OpenChanne! command, trans- 
fers image data in form of blocks. When the transfer of 



the image data has been completed, the image provid- 
ing device closes the transfer channel by a CloseChan- 
nel command, and reverses the flow control of the data 
transfer again by the Reverse command. This changes 
the data transfer direction of a device having a bidirec- 
tional data transfer function, i.e., a device having a data 
reception function and a data providing function. 
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Description 

BACKGROUND OF THE INVENTION 
s Field of the invention 

The present invention relates to a data transmission apparatus, system and method, and an image processing 
apparatus and more particularly, to a data transmission apparatus, system and method and an image processing 
apparatus in a case where an image providing device such as a digital camera is directly connected, via a serial 
70 interface based on, e.g., the IEEE 1 394 standards, to an image processing device such as a printer. 

Description ol Related Art 

Various types of systems which transfer data to a printer via a bus are known. For example, a known technique is 
is to output data Irom a computer to the printer by using a defacto standard interface such as a SCSI (Small Computer 
System Interface) or Centronics interface. 

In other words, the printer is connected to a personal computer (PC) as a host device via a parallel or serial interlace 
such as a Centronics or RS232C interface. 

Further a digital device as an image providing device such as a scanner, a digital still camera and a digital video 
20 camera is also connected to the PC. Image data inputted by the respective digital devices are temporarily stored in a 
hard disk or the like on the PC, then processed by an application software program or the like on the PC and converted 
into print data for the printer, and transferred via the above interface to the printer. 

In the above system, the PC has driver software programs respectively for controlling the digital devices and the 
printer The image data outputted from the digital devices is held as data of format which can be easily handled and 
25 displayed on the PC, by these driver software programs. The stored data is converted to the print data by an image 
processing method in consideration of image characteristics of input devices and image characteristics of output de- 
vices 

Today it is possible to for a new interlace such as an interlace based on the IEEE 1394 standards (hereinafter 

s , . «h on a in rtimrtht mnnori an imgnfl nrovidina device and a printer. In case of directly connecting 

30 the image providing device to the printer by the 1394 serial bus, an FCP (Function Control Protocol) operand may 
include print data Further, in the 1 394 serial bus, a register area may be provided such that data transfer is performed 
by writing data into the register area. 

Further, as the 1394 serial bus has a plurality of data-transfer control procedures, data transfer can be performed 
in methods appropriate to the respective devices. 
35 Further a printer having an image scanner function can perlorm printing and image scanning by selecting one ol 

printer and scanner functions. In printing, the printer receives print data from an image providing device, while in scan- 
ning, sends image data, as an image providing device, to a host computer That is, this printer changes a data transfer 
direction in accordance with its selected function. 

The printer having the above image scanner function must handle bi-directional data transfer, i.e., reception and 
40 transmission of image data. For this purpose, the printer has two data transfer methods and bi-directional data transler 
function. In such device, howlo change the data transfer direction is important. 

SUMMARY OF THE INVENTION 

45 The present invention has been made to solve the above problem, and has its object to provide a data transmission 

apparatus, system and method and an image processing apparatus which change a data transfer direction in accord- 
ance with a command. 

According to the present invention, the foregoing object is attained by providing a data transmission method for a 
data transmission system which transfers data between devices connected by a serial bus, the data transfer, started 
50 by first and second devices, performed on the basis of device information of the first and second devices provided in 
advance, wherein, in a case where the second device has a flow control function, an initiative of a flow control for the 
data transfer is moved from the first device to the second device in accordance with .a command issued by the first 
device, and the initiative is returned to the first device when the data transfer is completed. 

Further, the foregoing object is attained by providing a data transmission apparatus connected to a serial bus, 
55 comprising,' generation means for generating a command to reverse data transfer by a device connected.to the serial 
bus, and transmission means for transmitting the generated-command to said device. 

Further, the foregoing object is attained by providing a data transmission apparatus connected to a serial bus, 
comprising ' reception means for receiving a command from a device connected to the serial bus, and transler means 
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tor reversing data transfer based on the command received by said reception means. 

Further, the loregoing object is attained by providing a data transmission system for transJerring data through a 
serial bus. comprising, issuance means for issuing a command to a first device connected to the serial bus. and control 
means for reversing data transfer by a second device connected to the serial bus, based on the command issued by 
5 said issuance means. 

Further, the foregoing object is attained by providing a data transmission method for a data transmission system 
which transfers data between devices connected by a serial bus, the data transfer, started by first and second devices, 
performed on the basis of device information of the first and second devices provided in advance, said method com- 
prising, wherein, in a case where the second device has not a flow control function, a direction of the data transfer is 

10 reversed by a command issued by the first device, wherein the data is transferred the second device to the first device 
after the direction is reversed. 

Further, the foregoing object is attained by providing a data transmission apparatus connected to a serial bus, said 
apparatus comprising, transmission means for transmitting a command which notifies reversing a direction of data 
transfer, to a device connected to the serial bus, and reception means for receiving the data after the command has 

7£ been transmitted. 

Other features and advantages of the present invention will be apparent from the following description taken in 
conjunction with the accompanying drawings, in which like reference characters designate the same name or similar 
parts throughout the figures thereof. 

20 BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embod- 
iments of the invention and, together with the description, serve to explain the principles of the invention. 

25 Fig. t A is an explanatory view showing a general construction of a system to which the present invention is applied; 

Fig. 1 B is a block diagram showing an example of a network system constructed with an IEEE 1 394 serial interface; 

Fig. 2 is a block diagram showing the construction of the IEEE 1394 serial interlace; 

Fig. 3 is an explanatory view showing address space of the IEEE 1394 serial interlace; 

Fig. 4 is a cross-sectional view showing a cable for the IEEE 1 394 serial interlace; 
30 Fig. 5 is a timing chart explaining a Data/Strobe Link method; 

Figs. 6 to 8 are flowcharts showing a procedure of network construction in the IEEE 1 394 serial interlace; 

Fig. 9 is a block diagram showing an example of the network; 

Figs. 10A and 10B are block diagrams explaining bus arbitration; 

Fig. 11 is a flowchart showing a procedure of the bus arbitration; 
35 Fig. 1 2 is a timing chart showing transitional statuses in asynchronous data transfer; 

Fig. 13 is a diagram showing a packet format for the asynchronous transfer; 

Fig. 14 is a timing chart showing transitional statuses in isochronous data transfer; 

Fig. 15A is an example of a packet format for the isochronous transfer; 

Fig. 15B is a table showing the details of packet format fields for the isochronous transler in a 1394 serial bus; 
ao Fig. 16 is a timing chart showing transitional statuses in data transfer on the bus when the isochronous transfer 

and asynchronous transfer are mixedly performed; 

Fig. 17 is a schematic view showing the IEEE 1 394 serial interface in comparison with an OS! model; 
Fig. 18 is an explanatory view showing the basic operation of a LOGIN protocol; 
Fig. 19 is an explanatory view showing connection status in the IEEE 1394 serial interlace; 
45 Fig. 20 is a timing chart showing the flow of log-in operation; 

Fig. 21 is a schematic view showing a CSR preparing respective devices; 
Fig. 22 is a flowchart showing LOGIN processing in a host device; 
Fig. 23 is a flowchart showing LOGIN processing in a target device; 

Fig. 24 is an explanatory view showing a case in consideration of a device without the LOGIN protocol; 
so Fig. 25 is a schematic view showing the IEEE 1 394 serial interface in comparison with an OSI model, in the second 

embodiment; 

Fig. 26A is a table showing functions of a CSR architecture of the 1394 serial bus; 
Fig. 26B is a table showing registers for the 1394 serial bus; 
Fig. 26C is a table showing registers for node resources of the 1394 serial bus; 
55 Fig. 26D is an example of a minimum format of a configuration ROM of the 1 394 serial bus; 

Fig. 26E is an example of a general formal of the configuration ROM of the 1394 serial bus; 

Fig. 27A is a timing chart showing a request-response protocol with read, write and lock commands, based on the 

CSR architecture in a transaction layer; 
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Fig 27B is a timing chart showing services in a link layer; 

Fiq 28A is a timing chart showing an operation example o(a spirt transaction; 

Fig 28B is an explanatory view showing transitional statuses ot transler by the split transaction. 

Fig. 29 is an explanalory view showing an AV/C transaction in the 1 394 serial bus; 

Fig. 30 is an example ot the packet format tor the asynchronous transfer mclud.ng an FCP packet frame. 

Fig. 31 is an example of the slructure of an AV/C command frame; 

Fig. 32 is an example of the structure of an AV/C response frame; 

Fiq 33 is a schematic view showing a register map; nr ,„, ar . 
Fig. 34 is an explanatory view showing the flow of frames from an image prov.d.ng device to the pr.nter. 
io Fin 35 is an exolanatory view showing the construction ot a format register; 

' H I ™ Sanatory view showing the detailed construction of a status register of a common reg.ster group; 
f ? g . ll to an explanaU view showing the details of information held in a register GLOBAL of a common register 

F lg U 38 is an explanatory view showing the details of information held in a register LOCAL of the common register 

Fig U 39 is an explanatory view showing the details of information held in a register formatjl]; 
Fig 40 is an explanalory view showing the details ot information held in a register format[2]. 
Fig 41 is a table showing commands and responses to the commands; 
Fig 42 is an example of an image data formats supported by the DPP protocol; 
20 Fiq 43 is a timing chart showing the flow of format setting processing; 

Fia 44 is a timing chart showing the tlow of data-transfer method setting processing; 

Fia 45 Is an TxpLatory view showing a register map of registers necessary for transfer method 1 and transfer 

method 2. in address space of the 1394 serial bus; 

Fig. 46 is an example of a data packet frame; 
25 Fig 47 is an example of the structure of a data header; = „ cW 

Fig 48 is an explanatory view showing data packet frame processing in the printer in block transfer, 

Fig 49 is a timing chart showing commands and responses FreeBlock in the transfer method 1 . 

Fig 50 is a timing chart showing the flow of data transfer in the transfer method 1 ; 

Fiq 51 is a timing chart showing the How ot data transfer in the transfer method 2; 
30 Fiq 52 is a timing chart showing the commands and responses FreettiocK in me .rans.er me,.**. . ■ ■■' —«■"■ 

F? a . X is i ! timing chart showing a commands and responses WriteBlock in the transfer method 1 and the transfer 

Ss^atiming chart showing the commands and responses WriteBlock in the transfer method 1 and the transfer 

35 Fia^fe arimtno chart showing the flow of WriteBlock error processing upon occurrence of bus reset. 

Fig S I an TpLnatory view showing the construction of command registers, response registers and data reg- 
isters of the imaqe providing device and the printer, in a PUSH Large Buffer Model; 

EJ ^ ^!s a tS chart showing the flow of operate in a PUSH buffer mode, between the image proving device 
and the printer; 

ao Fig. 58 is an example of a data packet in a data frame; 

Fio 59 is an explanatory view of the relation between the data reg.ster and the buffer of the printer 

Rg 60 is an explanatory view showing the construction of the command registers, the response registers and the 

data reoisters of the image providing device and the printer, in a PULL buffer model; 

Rg ens aiming char, showing the flow of operation in the PULL buffer model between the image prov.ding 

?JS i^n expiatory view showing the re.ation between the data register and the buffer of the image providing 

Sg.'S is an explanatory view showing memory allocation for command registers and response registers lor flow 
control; and 

so Fiq 64 is a timing chart showing the flow of print processing. 

Fig 65 is a table showing commands and responses to the commands in a second embodiment 

Fig. 66 is a timing chart showing an example where a host computer logs ,n a scanner and [reverseslchanges the 

Z'SZiS^^ an example where the scanner transfers data to the host computer in accordance 
ss with a data request command issued from the host computer, as the controller o1 flow control; and 

Rg 68 is a timing char, showing a procedure in a case where the scanner logs ,n the host computer and performs 
data transler as the controller of the tlow control in place ot host computer. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Hereinbelow, a data transfer method according to an embodiment of the presem invention will now be described 
in detail in accordance with the accompanying drawings. 



[First Embodiment) 

Fig 1 A shows an example of general construction of a system to which the present invention is applied ^ere a 
PC 103. a prinler 102 and a digital video camera (DVC) 101 are connected v« a 1394 senal bus. Then the outline of 
the 1394 serial bus will be described below. 

[Outline of 1394 Serial Bus] 

With the appearance of general digital video cam recorder (VCR) and digital video disk (DVD) player there is a 
need tor transferring realtime and targe amount data such as video data and audio data (here.natter referred to as AV 
date" Transfer AV data in realtime to a personal computer (PC) or other digital devices, an .nterface capable of 
high-speed data transler is required. The 1 394 serial bus has been developed from the above potnt. 

Fta 1 B shows an example of a network system constructed with a 1 394 serial bus. Th.s system comprises devces 
A to H and the devices A and B. the devices A and C. the devices B and D. the devices D and E. the devc's C and 
F he dev"«s C and G, and the device C and H are respectively connected by a twisted pair cable for the 1 394 sera, 
bus These devices A to H may be computers such as a personal computer, or most compute r- P en P herah ^s such 
as a digital VCR. a DVD player, a digital still camera, a storage device using a storage med,um such as a ha d ^hsk or 
an optSl disk, a monitor such as a CRT or an LDC, a tuner, an image scanner, a film scanner, a pnnter. a MODEM, 

Z^W^La* of the printer may be any method, e.g., a laser-beam printing, an eiectrophotographic 
method using an LED. an ink-jet method, a thermal-transler method of ink melting or ink sublimat.on type and a thermo- 

Sen ^?onS,o m nt^ e en the devices may be made by mixedly using a daisy chain method and a node branching 
method, thus realizing high-freedom of connecting. ^ ^ „„, oH 

The respective devices have an ID, and they construct a network by identifying eac, , ,^ wu. .in a r D , .. 
by the 1 394 serial bus. For example, the devices respectively take a relaying role only by daisy^ham connect.ng the 
devices with cables for the 1394 serial bus. thus constructing a network. 

As the 1394 serial bus corresponds to Plug and Play function, it automatically recogn.zes a dev.ce connected to 
the cable thus recognizes connection status. In the system as shown in Fig. 1B. when a device .s removed from the 
network or a new device is added to the network, the bus is automatically reset (i.e., the current network constructing 

^ThTlMA serial bus has a data transfer speed defined as 100/200/400 Mbps. A device having a high transler 
speed supports a lower transfer speed, thus maintaining compatibility. As data transfer modes ^^T^ZT^ns 
ler mode (ATM) for transferring asynchronous data such as a control signal, an .sochronous transfer mode fo trans- 
ferring isochronous data such as realtime AV data are available. In data transfer, with.n each cycle (generally 125 us/ 
eye e) aTycle start packet (CSP) indicating the start of cycle is transferred, and then asynchronous and .sochronous 
data are mixedly transferred such that the isochronous data transfer is transferred prior to the asynchronous eterta 

Fig 2 shows the construction of the 1 394 serial bus, as a layer structure. As shown ,n F,g. 2 a connecto port B 0 
is connected to a connector at the end of a cable 81 3 .or the 1 394 serial bus. A physical ^ B 1^J'^. ™ 
in a hardware unit 600 are positioned as upper layers with respect to the connector port 810. The hardware unit 800 
Uprises interlace chips. The physical layer 811 performs coding, connection-related control and the hke, and the 
link layer 81 2. packet transfer, cycle-time control and the like. 

in a firmware unit 801. a transaction layer 814 manages data to be transferred (transacts data), and outputs 
commands Read. Write and Lock. A management layer 815 in the firmware unit 801 manages connect.on statuses 
and ID's of the respective devices connected to the 1 394 serial bus. thus manages the network construction. The above 
hardware and firmware units substantially constructs the 1394 serial bus. ^^^i 

In a software unit 802, an application layer 81 6 differs in software used by the system, and the data transfer protocol 
indicating how to transfer data on the interface is defined by a protocol such as a printer protocol or an AVC protocol 

Fig 3 shows address space of the 1394 serial bus. All the devices (nodes) connected to the 1394 senal bus have 
a unique 64 bit address. The 64 bit address is stored in a memory ot-the devices. Data communication with a designated 
destination device can be performed by always recognizing the node addresses o( the transmitting- and receiving-s.de 



nodes. 
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Addressing of the 1394 serial bus is made based on the IEEE 1212 standards, such that first 10 bits are allocated 
lor designating a bus number, then next 6 bits are allocated lor designating an node ID. 

48-bit address used in the respective devices are divided into 20 bits and 28 bits, and utilized in the unit of 256 
Mbytes In the initial 20-bit address space, "0" to "OxFFFFD" is called a memory space; 'OxFFFFE', a private space, 
"OxFFFFF" a register space. The private space is an address freely used in the device. The register space, holding 
information common to the devices connected with the bus, is used for communication among the respective devices^ 
In the register space, the initial 512 bytes are assigned to a register core (CSR core) as a core of a Command/ 
Status Register (CSR) architecture; the next 51 2 bytes, to a register of the serial bus; the next 1024 bytes, to a con- 
figuration ROM; and the remaining bytes, to a register unique to the device in a unit space. 

Generally tor the sake of simplification of bus system design for different node types, it is preferable that only the 
initial 2046 bytes are used for the nodes, and as a result, total 4096 bytes are used including the initial 2046 bytes for 
the CSR core, the register of the serial bus, the configuration ROM and the unit space. 

The 1394 serial bus has the construction as described above. Next, the features of the 1394 serial bus will be 
described in more detail. 

[Electrical Specification of 1394 Serial Bus] 

Fig 4 shows a cross-section of the cable of the 1394 serial bus. The 1394 serial cable comprises two sets of 
twisted pair signal lines and two power-source lines. This construction enables power supply to a device which lacks 
20 a power source or a device where a voltage is degraded due to a failure or the like. The direct^urrent voltage supplied 
by the power-source lines is 8 to 40V; the current is maximum 1 .5 A. Note that in the standards lor so-called DV cable, 
lour lines except the power-source line construct the cable. 

[DS-Link] 

25 

Fig 5 is a timing chart explaining a DS-Link (Data/Strobe-Link) method as a data transfer method. 
The DS-Link method, appropriate for high-speed serial data communication, requires two sets of two signal lines. 
That is one of the two sets of twisted-pair signal lines is used for sending a data signal, and the other one set of twisted- 
pair signal lines is used for sending a strobe signal. On the recerving side, an EXCLUSI VEOR between the data signal 

30 and the strobe signal is obtained so as io generate a ciock signal, in the DS-Link transfer, it is unnecessary to mix a 
clock signal into a data signal, therefore, transfer efficiency is higher than that in other serial-data transfer methods. 
Further as a clock signal is generated from the data signal and the strobe signal, a phase locked loop (PLL) circuit 
can be omitted, which attains downsizing of the scale of a controller LSI. Further, in the DS-Link transfer, it is unnec- 
essary to send information indicative of idle slatus when there is no data to be transferred, therefore, a transceiver of 

35 each device can be set in a sleep status, which reduces electric consumption. 

[Bus-Reset Sequence] 

The respective devices (nodes) connected to the 1 394 serial bus are provided with a node ID, and are recognized 
40 as nodes constructing the network. For example, when increase/decrease of the number ol nodes due to connection/ 
disconnection or power ON/OFF status of network devices, i.e., network construction changes and it is necessary to 
recognize a new network construction, the respective nodes delect the change of network construction, send a bus- 
reset signal onto the bus, and enter a mode for recognizing the new network construction. The detection of change of 
network construction is made by detecting change of bias voltage at the connector port 610. 
45 When the bus-resel signal is sent from one node, the physical layer 811 of the respective nodes receives the bus- 

reset signal, and at the same time, notifies the link layer 612 of the occurrence of bus reset, and forwards the bus- 
reset signal lo the other nodes. When all the nodes have received the bus-reset signal, a bus-reset sequence is started. 
Note that the bus-reset sequence is started when the cable is attached/detached, or the hardware unrt 800 has detected 
network abnormity or the like. Further, the bus-reset sequence is also started by a direct instruction to the physical 
so layer 611 such as host control by a protocol. As the bus-reset sequence is started, data transfer ts suspended during 
the bus reset, and after the bus reset, the data transfer is restarted in the new network construction. 

[Node-ID Determination Sequence] 

55 After the bus reset, the respective nodes start to obtain a node ID so as to construct a new network construction. 

A general sequence from the bus reset to node-ID determination will be described with reference to the flowcharts of 
Figs. 6 to 6. 

Fig. 6 is a flowchart showing a sequence from occurrence ol bus-reset signal to node-ID determination and data 
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iransfer At slop Si 01. the respective nodes always monitor occurrence ol bus-reset signal. When the bus-reset signal 
has occurred, the process proceeds to step S102. at which to obtain a new network construction in a state where the 
network construction has been reset, parent-child relation is declared between nodes connected lo each other. S ep 
S102 is repeated until it is determined at step S103 that the parent-child relation has been determined among all the 

As the parent-child relation has been determined, the process proceeds to step S104. at which one 'root (node)' 
is determined. At step S105, node-ID setting is performed so as to provide an ID to the respective nodes. The node- 
ID selling is made in a predetermined order ot the nodes. Step S105 is repeated until it is determined at step SI 06 
that the ID'S have been given to all the nodes. 

io As the node-ID selling has been completed, since the new network construction has been recognized by all the 

nodes, data transfer among the nodes is possible. At step S107, data transfer is started, and the process returns to 
step S1 01 at which occurrence of bus-reset signal is monitored again. 

Fig. 7 is a flowchart showing the sequence from the monitoring ol bus-reset signal (S101 ) to the root determination 
(S104) in detail Fig. 8 is a flowchart showing the node-ID setting (S105 and S106) in detail. 

75 In Fiq 7 at step S201. the occurrence of bus-reset signal is monitored, and as the bus-reset signal has occurred, 

the network construction is reset. Next, at step S202. as a first step lor re-recognizing the reset network construction, 
the respective devices reset its flag FL with data indicative of "leaf (node)". At step S203. the respective devices examine 
the number of ports, i.e.. the number ot other nodes connected to them. At step S204. based on the result of examination 
at step S203 the devices examine the number of undefined (i.e.. parent-child relation has not been determined) ports. 

20 The number of undefined ports is equal to that of the ports immediately after the bus resel. however, with the progress 
of determination of parent-child relation, the number of undefined ports detected al step S204 decreases. 

Only actual leaf (ves) can declare parent^hild relation immediately after the bus reset. Whether or not the node is 
a leaf is detected from the number of ports examined at step S203; i.e.. il the number of ports is "1" the node is a leaf. 
The leaf declares that 'this node is a child, and the connected node is a parent" at step S205. then term.nates the 

ss operation. , . IA . ■ „ iu„„„u« 

On the other hand, a node that detecled at slep S203 that the number of ports .s 'two or more is a branch . 
Immediately after the bus reset, as "undefined ports > 1 " holds, the process proceeds to step S206, at which the 1 ag 
FL is set with data indicative of "branch", then declaration of parent-child relation from another node is watted I at s ep 
S207 When the parent-child relation is declared from another node, the process returns to step S204 at which the 

so branch examines the number of undefined ports. II the number of undefined ports is "1 ", the branch can oec.are at 
step S205 that "this node is a child, and the connected node is a parent" to the node connected to the remaining port. 
If the number of undefined ports is still "two or more', the branch waits for declaration of parent«:h.ld relation from 

an0t Whe^ny a one e of ^branches (or exceptionally leaf(ves) which delayed declaring a child) detects that the number 
as of undefined ports is "0". the parent-child declaration of the overall network has been completed. The only one node 
that has "0" undefined port. i.e.. the parent of all the nodes, sets the flag FL with data indicative of a root at step S208. 
Then at step S209. the node is recognized as a root. 

in this manner, the procedure from the bus reset to the parent-child declaration among all the nodes in the network 

ao end Next a procedure of providing each node with an ID will be described. First, the ID setting is performed at the 
leaves Then, ID's are set in numerical order (from node number: 0) from leaves -> branches -» root. 

In Fig. 8, at step S301, the process splits in accordance with node type. i.e.. leaf, branch or root, based on the 

data set at the flags FL. . , , .. ., „. 

In case of leaf at step S302. the number ot leaves (natural number) in the network is set to a variable N. At step 

as S303 the respective leaves request a node number to the root. If a plurality ot requests have been made the root 
performs arbitration at slep S304. and provides a node number to one node at step S305. while notifies the other nodes 
of the result of acquisition of node-number indicating that the node number has been failed. 

A leaf that has not obtained a node number (NO at step S306) repeats the request for node number at step S303. 
On the other hand, a leaf that has obtained a node number notifies all the nodes of the obtained node number by 

so broadcasling ID information including the node number. As the broadcasting of the ID information has been completed, 
the variable N indicative of the number of leaves is decremented al step S308. Then, from the determination at step 
S309 the procedure from step S303 to step S308 is repeated until the variable N becomes "0" in the determination at 
step S309. When ID information on all the leaves have been broadcasted, the process proceeds to slep S310, tor 
setting ID's of branches. ...... co-m 

55 The ID setting for branches is performed substantially similar to the ID setting for the leaves. First, at step .5310. 

the number of branches (natural number) is set to a variable M. Al step S311 . the respective branches request the root 
lor a node number. In response to the requests, the root performs arbitration at slep S31 2. and provides a node number 
subsequent lo the last leal node number, lo a branch al step S313, while notifies the other branches ol the result ol 
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acquisition ot node-number indicating that the node number has been failed. 

A branch that has not obtained a node number (NO at step S314) repeats the request lor node number at step 
S31 5. On the other hand, a branch that has obtained a node number notifies all the nodes ot the obtained node number 
by broadcasting ID information including the node number. As the broadcasting ol the ID information has been com- 
5 pleted, the variable M indicative of the number of branches is decremented at step S31 6. Then, from the determination 
at step S317, the procedure from step S311 to step S316 is repeated until the variable M becomes '0° in the determi- 
nation at step S31 7. When ID information on all the leaves have been broadcasted, the process proceeds to step S31 8, 
for setting the ID of the root. 

At this time, it is only the root that has not obtained a node ID. At step S318, the root obtains the smallest number 
io that has not been provided to any other node as the node ID of the root, and at step S31 9, broadcasts ID information 
on the root. 

As described above, the procedure until the node ID's lor all the nodes have been set ends. Next, the sequence 
of node ID determination will be described with reference to the network example shown in Fig. 9. 

In the network in Fig. 9, a node B as a root is directly connected to its tower nodes A and C; the node C is directly 

75 connected lo its lower node D; and the node D is directly connected to its lower nodes E and F. The procedure of 
determining this hierarchical structure, the root node and the node ID's will be described be tow. 

After the bus reset has occurred, to recognize connection statuses of the respective nodes, parent-child relation 
is declared between ports of directly connected nodes, "parent" means a node at an upper level and "child" means a 
node at a lower level in the hierarchical structure. In Fig. 9 t the node that first declared parent-child relation after the 

20 bus reset is the node A. As described above, nodes (leaves) where only one port is connected can start declaration 
of parent -child relation. That is, if the number of ports is "1", it is recognized that the node is the end of the network 
tree, i.e., a leaf. The declaration of parent-child relation is started from the leaf which has first taken action among 
these (eaves. Thus, a port of the leave node is set as a "child", while the port of another node connected to the leave 
node is set as a "parent". In this manner, "child-parent" relation is sequentially set between the nodes A and B, between 

25 the nodes E and D, and between the nodes F and D. 

Further, among upper nodes having a plurality of ports, i.e., branches, parent-child relation is sequentially declared 
with respect to upper node(s), from the node that first received declaration of parent-child relation from the leaf. In Fig. 
9, first parent-chitd relation is determined between the nodes D and E and between the nodes D and F. Then the node 
D declares parent-child relation with respect to the node C, and as a result, a relation "child-parent" is set between the 

30 nodes D and C. The node C, thai has received the declaration ot parent-child relation from the node D, declares parent- 
child relation with respect to the node B connected to the other port, thus "child-parent' relation is set between the 
nodes C and B. 

In this manner, the hierarchical structure as shown in Fig. 9 is constructed. The node B, that has finally become 
the parent at all the ports, is determined as a root. Note that a network has only one root. In a case where the node B 
35 that has received declaration of parent-child relation from the node A immediately declares parent-child relation with 
respect to another node, the other node, e.g., the node C, may be the root node. That is, any node may be a root 
depending upon timing of transmitting declaration of parent-child relation, and further, even in a network maintaining 
the same construction, a particular node is not always become a root. 

As the root has been determined, the sequence of determining the respective node ID's is started. Each node has 
ao a broadcast function to notify its ID information to ailthe other nodes. ID information includes a node number, information 
on a connected position, the number of ports, the number of ports connected to other nodes, information on parent- 
child relation on the respective ports and the like. 

As described above, the assignment of node numbers is started from the leaves, in numerical order, node number 
= 0, 1, 2 is assigned. Then, by the broadcasting ol ID information, it is recognized that the node number has been 
45 assigned. 

As all the leaves have obtained a node number, node numbers are assigned to the branches. Similar to the as- 
signment of node numbers to the leaves, ID information is broadcasted from the branch that received a node number, 
and finally, the root broadcasts its ID information. Accordingly, the root always has the greatest node number. 

Thus, as the ID setting of the overall hierarchical structure has been completed and the network has been con- 
50 structed, then the bus initialization is completed. 

[Control Information for Node Management] 

The CSR core as shown in Fig. 3 exists on the register as a basic function of the CSR architecture for node 
55 management. Fig. 26A shows the positions and functions of the registers. In Fig. 26A, the offset is a relative position 
from "OxFFFFFOOOOOOO. 

In the CSR architecture, the register for the serial bus is arranged from "OxFFFFF0000200\ Fig. 26B shows the 
positions and functions of the registers. 
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Further, information on node resources ot the serial bus is arranged trom "OxFFFFF0000800". Fig. 26C shows the 
positions and lunctions of the registers. 

The CSR architecture has a configuration ROM for representing functions of the respective nodes. The configu- 
ration ROM has a minimum format and a general format, arranged from «OxFFFFF0000400". As shown in Fig. 26D, 
£ the minimum format configuration ROM merely shows a vendor ID which is a unique numerical value represented by 
24 bits 

As shown in Fig 26E. the general format configuration ROM has information on a node. In this case, the vendor 
ID in this formal is Included in a •rool.directory-. Further, •bus_info_block- and Yoot&unitjeaves' include unique dev.ee 
number including the vendor ID. represented by 64 bits. The device number is used after network reconstruction by 
io bus reset operation, to continue recognition of the node. 

[Serial Bus Management] 

As shown in Fig 2, the protocol of the 1394 serial bus comprises a physical layer 811, a link layer 812 and a 
is transaction layer 814. This provides, as the serial bus management, a basic function for node management and bus 
resource management, based on the CSR architecture. 

Only one node which performs bus management (hereinafter referred to as "bus management node ) exists on 
the same bus, and provides the other nodes on the serial bus with management function which includes cycle master 
control, performance optimization, power source management, transmission speed management, constructs man- 

so agement and the like. . 

The bus management function briefly divides into a bus manager, an isochronous resource manager and a node 
control function. The node control is a management function which enables communication among the nodes in the 
physical layer 811 the link layer 812, the link layer 812, the transaction layer 814 and an application program by the 
CSR The isochronous resource manager, which is a management function necessary for isochronous-type data trans- 
ss fer on the serial bus. manages assignment of transfer bandwidth and channel number to isochronous data. For this 
management, after bus initialization, the bus management node is dynamically selected from nodes having the iso- 
chronous resource manager function. 

Further in a construction without a bus management node on the bus, a node having the .sochronous resource 
manaonr funciion oerforms a part of the bus management such as the power source management and cycle master 
so control Further, the bus management is a management function as service to provide a bus control interlace to an 
application program. The control interlace uses a serial-bus control request (SB_CONTROL.request), a seral-bus 
event control confirmation (SB_CONTROL.confirmation) and a serial-bus event indication (SB_EVENT.mdicat.on). 

The serial-bus control request is used when an application program requires the bus management node to perform 
bus reset, bus initialization, representation of bus-status information, and the like. The serial-bus event control confir- 
ms mation is the result of the serial-bus control request, and is notified 1rom the bus management node to the application 
for confirmation. The serial-bus event control confirmation is made as notification of an asynchronously-caused event 
from the bus management node to the application. 

[Data Transfer Protocol] 

AO 

The data transfer by using the 1394 serial bus simultaneously sends isochronous data (isochronous packet) which 
must be periodically transmitted, and asynchronous data (asynchronous packet) which can be transmitted/received at 
arbitrary timing, further, ensures real-time transmission of isochronous data. In the data transfer, a bus use right is 
requested prior to transfer, and bus arbitration is performed to obtain bus use permission. 
as m the asynchronous transfer, a transmitting node ID and a receiving node ID are sent wilh transfer data as packet 

data. The receiving node confirms the receiving node ID. i.e., its node ID, receives the packet, and returns an acknowl- 
edge signal to the transmitting node. Thus, one transaction is completed. 

In the isochronous transfer, a transmitting node requires an isochronous channel with a transmission speed, and 
a channel ID is sent with transfer dala as packet data. A receiving node confirms a desired channel ID and receives 
so the data packet. The necessary channel number and transmission speed are determined by the application layer 816. 

These transfer protocols are defined by the physical layer 811 . the link layer B12 and the transaction layer 81 3. 
The physical layer 811 performs physical and electrical interface with the bus, automatic recognition of node connection, 
bus arbitration for a bus use right among nodes, and the like. The link layer 812 performs addressing, data checkmg, 
packet transmission/reception and cycle control for isochronous transfer. The transaction layer 814 performs process- 
55 ing relating to asynchronous data. Hereinbelow, the processings in the respective layers will be described. 
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[Physical Layer] 
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Tho bus arbitration in the physical layer 811 will be described. 

Th l Ys9A se^ bus always performs arbitration ol bus use right prior to data transfer. The dev.ces connected to 
the 1 394 serial bus respective^ relay a signal transferred on the network, thus constructing a logical bus-type networ 
signal to all the devu.es within the network. This necessitates bus arbitrate to avo,d packet conflict. 
As a result of bus arbitration, one node can transfer data during a certain period. 

Figs 10A and 10B are block diagrams explaining the bus arbitration. Fig. IDA shows operate to request a bus 
use riant* and Fiq 10B, operation to allow to use the bus. 

When the bus arbitral is started, a single or polity ot nodes respectively request a bus use right to use th 
^ T ,e ^r„n.' nndP In Fio 1 0A the nodes C and F request a bus use right. The parent node (node A in Fig. 1 0A) 
X has * Sa^reCS re^ne Toques, by furJr requesting a bus use right to its parent node. The request 
i* forwarded to a root (node B in Fig. 10A) that finally perlorms arbitration. 

Te tot Lt S ecerved the Request for bus use right determines a node to be provided w,.h the bus use nghl 
This aLTat on can be performed on.y by the root. The node that dominated in the arbitration ,s piov.ded w'ththe bus 
use 4m Fig 10B shows that the node C has obtained the bus use right and the request from the node F has been 

reie Theroot sends a DP (data prefix) packet to nodes .ost in the bus arbitrate so as to notify that their requests have 
been rejected. The requests from those nodes are held by the next bus arbitration. 
20 Thus ihe node that obtained the bus use permission starts data transfer. _ , c 

The sequence of the bus arbitration will be described with reference lo Ihe flowchart of Fig. 11 . 

To sirt data transfer by a node, the bus must be in idle status. To confirm that data transfer has been completed 
and [he bTs fs u entt S status, each node detects a gap .ength o. a predetermined idle 

gap) se«t; 'each transfe" mode, and it determines whether or not the bus is currentiy in ,dle status based on the detect.on 

" ^'"At step S401 the node determines whether or not a predetermined gap length corresponding to asynchronous 
data isochronous data to be transferred has been detected. So far as the node has not detected the P^e * ™! " 
gap length??, cannot request a bus use righ, to start data transfer, according*, the node wa,s unf. the predetermined 

93P W^n rpre^t^d gap .ength has been detected a, step S401 . the node ^^^^ ^ 
is data to be transferred at step S402. If YES, il issues a signal requesting a bus use right to the root at step S403 ^As 
Lhown n F% 10A this signal requesting the bus use right is relayed by the respective dev.ces ,n the network, and 
forwarded to the root. If it is determined at step S402 that there is no data lo be transferred, the process returns to step 

S4 ° At step S404 if the root has received a single or plurality of request signals lor the bus use right it examines the 
numbed nodes 'requesting the bus use righ. at step S405. From the determination at step S405, rt the number of he 
ncls requeued the but use right is one. that node is provided with bus use permission immediately after the require- 
m^On the Mother hand, if the number of the nodes is more than one. arbitration is performed to determme one node 
Tbe p?ov^d with the bus use right immediate* after the requirement. The arbitration does not a -ys Prov.de a bus 
use riqht lo the same node, but equally provides a bus use right to the respective nodes (fa.r arbitration). 

SI processing at the root branches at step S407 into pressing tor ,he node dom.nated .n the ^arbi urtor at s P 
^406 and orocessino lor the other nodes lost in the arbitration. In a case where there is one node that requested the 
bu use rX°r oTe node has dominated in the arbitration, the node is provided with an permission signal .ndicat-ve 
of ous ^mission a, step S408. The node starts data (packet) transfer ^^J^^^SS^S, 
sional (step S410) On the other hand, the nodes lost in the arb.trat.on receive a DP (data prefix) pac ket indicative oi 
r£on oHhe bus use request a. step S409. The processing for the node that received the DP packet returns to si p 
sToi 1c ^requesla bus use righ. again. A.so. the processing for the node that completed data transfer at step S410 
returns to step S401 . 
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so [Transaction Layer] 



The transaction layer includes a read transaction, a write transaction and a lock transaction. 

Ja l ^d tanTaLtL. an initiator (requiring node) reads data from a specific 
(response node) In a wrrte transaction, the initiator writes data into a specrf.c address of the memory of the largetJn 
a oTkTransaCion. the initiator transfers reference data and update data to the 

with data of the address of the target, into a designation address to specify a specif.c address of the target. Data 
ihe designation address is updated by the upda.c data. «„-hit«»rime 
Fig. 27 A shows a request-response protocol wi.h read, write and lock commands, based on the CSB aichrtecture 
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in the transaction layer. In Fig. 27A. the request, notification, response and confirmation are service units in the trans- 

a °"°A iTansatfton request (TR_D ATA. request) is packet transfer to a response node; a transaction indteatiorV(TR- 
DATA indication) is notification of arrival of the request to the response node; a transacts response (TR_DATA.re- 
5 sponse) is transmission of acknowledgment; and a transaction confirmation (TR_DATA.con1irmation) ,s reception of 
acknowledgment. 

|Link Layer] 

70 Fiq 27B shows services in the link-layer 812. The services are service units of a link request (LK_D ATA. request) 

to require packet transfer from the response node, a link indication (LK_DATA. indication) indicating packet reception 
to the response node, a link response (LK_D ATA. response) as acknowledgment transmitted from the response node, 
a link confirmation (LK_DATA.confirmation) as confirmation of the acknowledgment transmrtted from the response 
node. One packet transfer process is called a subnotion including an asynchronous sub-action and an isochronous 

is sub-action. Hereinbelow. the respective operations of the sub-actions will be described. 

(Asynchronous Sub-action] 

The asynchronous sub-action is asynchronous data transfer. 
so Fig 12 shows transition in the asynchronous transfer. In Fig. 1 2. the first sub-action gap represents the idle status 

of the bus. At a point where the idle lime has become a predetermined value, a node which is to perform data transfer 
requests a bus use right, then bus arbitration is executed. 

When the use of bus has been allowed by the arbitration, data in the form of packet is transferred, and a node 
which receives the data sends a reception acknowledgment code ACK as a response, or sends a response packet 
25 after a short gap called ACK gap, thus the dala transfer is completed. The code ACK comprises 4-bit information and 
a 4-bit checksum. The code ACK. including information indicative of success, busy or pending status, is immediately 

sent to the data-sender node. ~n/~ < 

Fiq 13 shows a packet format for asynchronous transfer. The packet has a data area, a data CRC area for error 
correction, and a header area in which a destination node ID. a. source node ID. a transfer data length and various 

30 codes are written. . . „ . „, „„„, 

The asynchronous transfer is one-lo-one communication from a sender node to a receiver node. A packet senl 
from the sender node is relayed by the respective nodes in the nelwork. however, as these nodes are not designated 
as the receiver of the packet, they ignore the packet, then only the receiver node designated by the sender node 
receives the packet. 



35 



[Split Transaction] 



The services in the transaction layer 81 4 are performed as a set of transaction request and transaction response, 
as shown in Fig. 27 A. if the processings in Ihe link layer 81 2 and the transaction layer 814 of the target (response 
ao node) are performed at a sufficiently high speed, the request and the response are not pertormed as independent sub- 
actions but as one sub-action in the link layer 812. However, if the processing speed of the target .s low. the request 
and the response must be processed by independent sub-actions. This is called a split transaction. 

Fiq 28A shows an operation example ol the split transaction. In Fig. 28A, in response to a write request from a 
controller as an initiator (requiring node), a target returns a pending. The target relurns confirmation informat.on to the 
as write request from the controller, thus gains lime for data processing. When a sufficient period for the data Pressing 
has elapsed, the target sends a write response to the controller, thus completes the write transaction. Note that another 
node can perform the operation of the link layer 612 between the request and response sub-actions. 

Fig. 28B shows transitional statuses of transfer in case of the split transaction. In Fig. 28B. a sub-aclion 1 represents 
the request sub-action; and a sub-action 2. the response sub-action. 
so In the sub-action 1 . the initiator sends a data packet indicative of the write request to the target, and the target 

receives the data packet, returns -pending- indicative of the confirmation of the above inlormalion. as an acknowledge 
packet. Then, the request sub-action is completed. 

Then when a sub-action gap has been inserted, the target sends a write response as a data packet wrth no data, 
in the sub-action 2. The initiator receives the data packet, returns a 'complete' response as an acknowledge packet. 
55 Then, the response sub-action is completed. " ' . . . , 

Note that the period from the completion of the sub-adion 1 to the beginning of the sub-action 2 can be mm.m.zed 
to a period corresponding to the sub-action gap, while maximized to a period corresponding to a maximum waiting 
period set in the nodes. 
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[Isochronous Sub-action] 



Isochronous transfer, which can be regarded as the greatest feature ol the 1394 serial bus is appropriate to mul- 
timedia data transfer which requires realtime transfer of, especially, AV data. 

£ Further, the asynchronous transfer is one-to-one transfer, whereas the isochronous transfer is broadcasting trans- 

fer from one sender node to all the other nodes. 

Fig. 14 shows transition in the isochronous transfer The isochronous transfer is executed on the bus in a prede- 
termined cycle, called 'isochronous cycle". The period of the isochronous cycle is 125 u.s. A cycle start packet (CSP) 
indicates the start of the isochronous cycle for synchronizing the operations of the respective nodes. When data transfer 

w in a cycle has been completed and a predetermined idle period (sub-action gap) has elapsed, a node which is called 
'cycle master" sends the CSP indicative of the start of the next cycle. That is, this interval between the issuance of 
CSP's is 125 |is. 

As channel A, channel B and channel C in Fig. 14, the respective packets are provided with a channel ID, so that 
plural types of packets can be independently transferred within one isochronous cycle. This enables substantially- 
75 realtime transfer among the plural nodes. The receiver node can receive only data with a predetermined channel ID. 
The channel ID does not indicate an address of the receiving node, but merely indicates a logical number with respect 
to the data. Accordingly, one packet sent from a sender node is transferred to all the other nodes, i.e., broadcasted. 

Similar to the asynchronous transfer, bus arbitration is performed prior to the packet broadcasting in isochronous 
transfer. However, as the isochronous transfer is not one-to-one communication like the asynchronous transfer, the 
20 reception acknowledgment code ACK used as a response in the asynchronous transfer is not used in the isochronous 
transfer. 

Further, an isochronous gap (iso gap) in Fig. 14 represents an idle period necessary for confirming prior to iso- 
chronous transfer that the bus is in idle status. 

If the predetermined idle period has elapsed, bus arbitration is performed with respect to node(s) desiring isochronous 
25 transfer. 

Fig. 15A shows a packet format for isochronous transfer. Various packets divided into channels respectively have 
a data field, a data CRC field for error correction and a header field containing information such as a transfer-data 
length, a channel No., various codes and error-correction header CRC as shown in Fig. 15B. 

30 [Bus Cycle] 

In practice, both isochronous transfer and asynchronous transfer can be mixedly performed on the 1394 serial 
bus. Fig. 16 shows transition in the isochronous transfer and asynchronous transfer mixedly performed on the 1394 
serial bus. 

35 The isochronous transfer is performed prbr to the asynchronous transfer because after the CSP, the isochronous 

t ransf er can be started with a gap (isochronous gap) shorter than the idle period necessary for starting the asynchronous 
transfer. Accordingly, the isochronous transfer has priority over the asynchronous transfer. 

In the typical bus cycle as shown in Fig 1 6, upon starting the cycle #m, a CSP is transferred from the cycle master 
to the respective nodes. The operations of the respective nodes are synchronized by this CSP, and node(s) that waits 

ao for a predetermined idle period (isochronous gap) to perform isochronous transfer participates in bus arbitration, then 
starts packet transfer. In Fig. 1 6, a channel e, a channel s and a channel k are transferred by the isochronous transfer. 

The operation from the bus arbitration to the packet transfer is repeated for the given channels, and when the 
isochronous transfer in the cycle #m has been completed, the asynchronous transfer can be performed. That is, when 
the idle period has reached the sub-action gap for the asynchronous transfer, node(s) that is to perform the asynchro- 

45 nous transler participates in bus arbitration. Note that only if the sub-action gap for starling the asynchronous transfer 
is detected, after the completion of isochronous transfer and before the next timing to transfer the CSP (cycle synch), 
the asynchronous transfer can be performed. 

In the cycle #m in Fig. 1 6, the isochronous transfer for three channels is performed, and then two packets (packet 
1 and packet 2) including ACK are transferred by the asynchronous transfer. When the asynchronous packet 2 has 

so been transferred, as the next cycle synch point to start the subsequent cycle m+1 comes, the transfer in the cycle *m 
ends. Note that during the asynchronous or isochronous transfer, if the next cycle synch point to transfer the next CSP 
has come, the transfer is not forcibly stopped but continued. After the transfer has been compleled, a CSP for the next 
cycle is transferred after a predetermined idle period. That is. when one isochronous cycle is continued for more than 
125 *is, the next isochronous cycle is shorter than the reference period 125 jis. In this manner, the isochronous cycle 

ss can be lengthened or shortened based on the reference period 125 ^is. 

However, it may be arranged such that the isochronous transfer is performed in every cycle, while the asynchronous 
transfer is sometimes postponed until the next cycle or the cycle further subsequent lo the next cycle, so as to maintain 
realtime transfer. The cycle master also manages information on such delay. 
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|FCP) 

In an AV/C protocol, a Function Control Protocol (FCP) is provided to control devices on the 1394 serial bus. For 
transmission ot control commands and responses in the FCP protocol, an asynchronous packet det.ned by the IEEE 
1394 standards is employed. In the FCP protocol, a node on the controller side is called a controller, and a node on 
the controlled side, a target. An FCP packel Irame sent from the controller to the large! is called an AV/C command 
Irame- an FCP packet frame returned from the target to the controller, an AV/C response (rame. 

Fig 29 shows a case where a node A is a controller and a node B is a target. In ihe register address prov.ded tor 
the respective nodes, 512 bytes trom "OxOOOOBOO" are assigned to a command register; and 512 bytes from 
■OxOOOODOO- are assigned to a response register. Data is written into the register of a designated address by a packet 
frame using the asynchronous transfer. The relation between the transmission of the AV/C command frame by the 
controller and the response with the AV/C response Irame by the target is called an AV/C transaction. In a general AV/ 
C transaction a target wh ich has received a command frame must send a response frame to a controller wrthm 1 1 00 ms. 

Fig 30 shows the packet format for the asynchronous transfer including an FCP packet frame. A command frame 
or a response frame is inserted into a data area of the asynchronous data packet as shown in Fig. 15A, and the AV/C 

transaction is performed. 

Fiq 31 shows the structure of the AV/C command frame. Fig. 32 shows the structure of the AV/C response frame. 
As Ihe FCP packet frame, an FCP data part is arranged after "ctype". 'response'. "subunitjype" and "subunrtJD" in 
the header. 

•ctype' indicates a command type in the command frame, with stalus "CONTROL", "STATUS", "INQUIRY" or 
"N^)TI FY" 

"response" indicates a response code in the response frame, with status "ACCEPTED", "REJECTED", 
"IN_TRANSIT10N", "IMPLEMENTED", "CHANGED" or "INTERIM". 

Further "subuniMype" indicates the classification of a device, and "subunitJD" indicates an instance number. 

The FCP data part has an operation code (opcode) + operand (oprand) structure. The target is controlled and the 
AV/C response is performed by using various AV/C commands. 

The operation code (opcode) in the command frame as shown in Fig. 31 is one of commands as shown in Fig. 41 
30 The respective commands are perlormed wrth contents according to the command types set at the s ciype-. 

A command where the "ctype" designates the status "CONTROL" is a control command used for controlling the 
target device or setting the target to the content set after the operand (oprand). A command where the "ctype^desig- 
nates the status "STATUS" is used for obtaining a status corresponding to the command. A command where the ctype 
designates the status "INQUIRY" is used for inquiring about contents which can be set by the command. A command 
35 where the "ctype" designates the status "NOTIFY" is used tor performing confirmation of the command. 

In each command, necessary content is set at the operand, and the command is written into the command frame. 

In the operation code of the response Irame, one of response codes as shown in Fig. 41 is set. Each response 
has an operand corresponding to the response. As information indicating whether the execution of the command has 
been normally completed or ended with error, is set at the operand, error processing can be performed in accordance 
40 with the operand. 

[Communication Using LOGIN Protocol] 

Fig 1 7 shows the interlace of the 1 394 serial bus in comparison with respective layers of an OSI model often used 
as in a LAN In the OSI model, a physical layer 1 and a data link layer 2 respectively correspond to a physical layer 811 
and a link layer 81 2 (both shown in Fig. 2) in a lower layer 4 of the 1 394 serial bus interlace. In the 1 394 serial bus 
interface, a transport protocol layer 5 and a presentation layer 6 as upper layers correspond to an upper Mayer 3 o OS 
model including a network layer, a transport layer, a session layer and a presentation layer. Further, a LOGIN protocol 
7 operates between the lower layer 4 and the transport protocol layer 5 of the 1 394 serial bus interface. 
so ' In Example 1 in Fig. 17, by providing the LOGIN protocol 7 to a device based on a serial bus protocol (SBP-2) 8 
for a peripheral device such as a printer, the peripheral device uses a protocol based on the protocol SBP-2 to notify 
a target device of data transfer with the target device. In Example 2, with respect to a device protocol 9 specialized on 
the 1394 serial bus interface, by providing the LOGIN protocol 7 to respective devices, the devices can determine 
whether or not the target device supports their protocol, with each other. 
55 Fig 18 shows the basic operation of the LOGIN protocol. When a printer device executes a print task 10 from a 

host device, the printer device first selects one ot printer protocols A to C for data communication, based on commu- 
nication by the LOGIN protocol 7. ' . 4 , T h«« ;* 
Thereafter, the printer device perlorms print data transfer in accordance with the selected pr.nter protocol. Thai is, 
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upon connection between the printer device which supports a plurality of printer protocols and a host dev.ee the pr ntc 
Sice fkst judges the transport protocol 5 o. the hos, device based on the LOGIN protocol 7, selects a pnnter protocol 
corresponding to the transport protocol 5 of the hos. device, and performs .ranster/reception of P nn. data or commands 
in accordance with the selected printer protocol, thus perlorms the pr.nt task JO „,„ riUr . R u 0 ,M wi , h 

Fig 1 9 shows connection status in the 1 394 serial bus. where devices (PC1 2, scanner 1 3 and VCR 1 4 etc. with 
the LOGIN protocol 7 are connected to a printer 11 corresponding to plurality of printer protocols. The pnnler 11 can 
process print tasks from the respective devices by changing the printer protocol in accordance with the transport pro- 
tocol 5 of a device that requests connection with the printer device. 

Fig. 20 shows the flow of log-in operation. At STEP 1: 

The host device locks a target device (a multi-protocol printer in this case). 

The target device examines the capability of the host device (including the transport protocol). Note that the ca- 
pability has been stored into a capability register 503 (to be described later) of the host dev.ee. 
The target device sets the capability (including the transport protocol) ol the host device. 

At STEP 2: 

Print data is transferred by the protocol determined at the STEP 1 



SO At STEP 3: 

The host device disconnects the connection with the target device. 

Fig 21 shows control/status register (CSR) which is prepared by a printer as the target device so that the LOGIN 

ss protocol is ins.al.ed, including a lock ^ 

are provided in predetermined addresses in initial unit space in the address space of the 1394 serial bus That , as 
shown in Fig. 3, within the 48-bit address area provided to the devices. "OxFFFFF" in the f.rst 20 -Ms .8 call ^register 
space', wherein a register (CSR core, as the core of the CSR architecture is arranged ,n ^ *«t 5J2 
information common to devices connected via the bus is provided In this register space. Further. 0-0xFFFFD is cal ed 

30 -memory space", and -OxFFFFE", "private space'. The private space is an address wntcn can oe .reeiy useo in u.. 

device for communication among the devices. - . , , ^„ =h io *\at„* 

The lock register 501 indicates a locked status of a resource, with a value "0" indicative of log-in enable status, 
and any value but -0\ an already-logged-in and locked status. The capability register 503 indicates a protocol where 
each bn represents a protocol, with a value "1 • bit indicating that a corresponding protocol can be set while a value 
as -0- bit. that a corresponding protocol cannot be set. The protocol register 502 indicates *™™*^J»*«** ™ 
is. each bit of the protocol register 502 corresponds to each bit of the capability reg.ster 503. and the value of a bit of 
the protocol register 502 corresponding to the set protocol is "1". 

Fig. 22 is a flowchart showing LOGIN processing in the host device. ^^hintv 
To start the LOGIN processing, first, the data of the lock register 501 . the protocol reg.ster 502 and the eapab Irty 
<o register 503 of a target device e.g., a printer, to be .ogged-in, is checked by a read ""^^^J™^ 
data of the capability register 503, it is examined whether or not the target dev.ee supports a protocol used by ^ .host 
device for communication (step S601). If the target device does not support the protocol of the host dev.ee, the LOGIN 

Drocessinq is terminated at step S602. . . . 

Further, if the data value of the lock register 501 is not "0", it is determined that another device .6 in logged-in 
45 status, and the LOGIN processing is terminated. If the data value of the lock register 501 is "0", n b determ.ned that 

log-in is currently possible (step S602). hw u^itinn 

in case of log-Tenable status, the process moves to resource lock process.ng where the log-in .s set by - wn ting 
■f into the lock register 501 of the printer by using a lock transaction (step S603). The target dev.ee e locked ,n this 
status and it is uncontrollable from other devices and the register values cannot be changed. . 

so As described above, in the status where the resource of the target device is locked, protocol setting is P^ormed 

next. As the printer as the target device of the present embodiment supports a plurality of pnnter pro ^^^ocols the pnnle 
must be inlormed of the protocol which can be used by the host device before it receives print data. In the present 
embodiment, the protocol to be used is notified to the printer by setting the corresponding brt of the protocol reg.ster 
502 of the printer by a write transaction (slep S604). ......... 4 . ^ ■„„ ^„ rt 

ss At this point, as the protocol used by the host device lor communication has been notified to the target device and 

the targe, device is in locked stalus. the host device that is currenlly logged in the targe, device perlorms data (pnn. 
data in this case) transfer (step S605). „„•„,,„, 
As .he data transfer has been completed, .he hos. device logs ou. I.om the printer by cleanng the lock register 
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501 and the capability register 503 ot the target device (step S606). 

Fiq 23 is a flowchart showing the LOGIN processing in the printer as the target dev.ee. 

The printer generally waits lor log-in Irom a host device. As a print request trom a host dev.ee is started by reading 
data values from the lock register 501, the protocol register 502 and the capability register 503 
registers must be in read-enable status. This processing will be described on the assumption that a host device which 
is to perform printout has locked the printer (step S701). m ^ . . . „ a 

The printer waits tor notification ot an available protoco. .rom the host device (step S702>The printer ^receives the 
notification ot available-protoco. in locked status so as to maintain the protocol register 502 unchanged by another 
device's request in mid-course of the log-in processing. „,„ t/ ^„, ,„ , ho nn mt>ri 

When the available protocol has been assigned (step S703), the printer switches its own protoco to the notified 
protocol (steps S704, S706 and S708). and performs communication in accordance with the protocol of the host dev.ee 

(S,e ^In^ll™^ has been completed, the printer confirms that the lock register 501 and the capability 
register 503 have been cleared (slep S710), and returns to the log-in wailing status (step S701). 

[Example in Consideration of Device without LOGIN Protocol] 

Fig 24 is an explanatory view showing a case in consideration of a device without the LOGIN protocol 7. Compared 
with the first example as shown in Fig. 18. this example is applicable to a device having a protocol 0 . in which the 
LOGIN protocol 7 is not installed. That is. to assure the device only corresponding to the conventional protocol! D (a. 
g AV/C protocol) of print operation, as well as devices having the LOGIN protocol 7. the pr,n er s,de has th ,p rotccol ^ 
9 In this case/if the printer recognizes, by a print request perlormed at the beginning of connection, that the host 
device does not correspond to the LOGIN protocol 7. the printer tries communication with the host device by using he 
protocol D. and if the communication can be established, the printer executes the print task 10 ,n accordance wrlh the 

protocol a interface according to this example in comparison with the OSI model. Example 

3 uses as a m^cl a n AV device 15 based on the AV/C protocol. In the AV device 15. the LOGIN protocol 7 « not 

d uses, as a nmuoi, an ™ ^ ..^.^ . nniM — i^^t 7 ic not in^tallpri but a non-standard 
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Lt S aned aS Ex a amS " u^a^eTa ^ ^.N protoco, 7 is not installed, but a nonstandard 

orotocol lor scanner is installed. 

That is. regarding a device in which the LOGIN proircoi 7 is no! installed, il the pnnter can peuor.n curnrnun^uo, , 
using the protocol of the device, the printer can perform print task from the device. This increases the types ot devices 
1hat can use the printer. 

[Direct Print Control] 

Hereinbelow. print procedures in the printer and the image providing device will be described. In this case, a Direct 
Print Protocol (DPP), is employed as a protocol to directly connect the primer and the image providing device, and 
enable the printer to form an image based on image data provided from the image P^'^™°* 

The DPP protocol basically comprises a command register (command) lor writing a command in the n, tial un. 
space (the unit space in Fig. 3). a response register (response) lor writing a response to the command, a data regisler 
£ wrUing transfer data, and a format register (format) for handling format information corresponding to data 

tormat for each transfer data. A , ^ 4 , A(fl 

Fig. 33 shows a register map in which the command register and the response register are the sa™ 
described in Fig. 29. In the following description, the image providing device as a controller provides image data to the 
printer as a target and an image is printed based on the image data. 

A command register 42-1 . arranged from a fixed address -OxFFFFFOOOOBOO- on the pnnter side has a 51 2 byte 
meri^pace in ^ which the image providing device writes various commands for the printer. If the WP™*W 
device side also has a command register, the printer can write commands into the register. The command written into 
the command reqisler is called a command frame. 

"Response register 42-2. arranged from fixed address -OxFEFFFOOOODOO'. has a 
which a response is written with respect to the various commands written from the image providing device to the , p inter 
If the printer side also has a response register, the image providing device can write a response into the register The 
response written into the response register 42-2 is called a response frame. Note that ,n Fig. 29. the upper address 

Paf1 A 0 St7registr42 e 3.' having a default address VFFFFOOOSOOOh-. is set al an arbitrary effective address by com- 
mands "BlockAddress" and -BufferConfig' (commands to define theaddress of the data register). The memory space 
ot To data register 42-3 is set with a range predetermined by commands -B.ockSize- and ■BuflerConf.g- (^rnands 
,o define the memory space o. the data register). The data register 42-3 is used tor data transle, between the .mage 
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providing device and ihe printer Upon printing, the image providing device writes print data tor the printer into this 
register. The print data is based on a pre : set image format. The data written into the data register 42-3 is called a data 
frame. 

A lormat register 42-2 is a set of registers corresponding to various data formats to be described later. The re- 
5 spective registers are used for setting format information necessary for the respective data formats. That is, the format 
register 42-2 is used for writing the format information for the printer from the image providing device. The format 
information written into the format register 42-2 is called a formal frame. 

Fig 34 shows the flow of frames from the image providing device to the printer, i.e. , shows the flow of the command 
frame, the response frame, data frame and the lormat frame. The printer performs printing in accordance with the 
to frames outputted from the image providing device. 

A command sent from the image providing device to the printer is written as a command frame into a command 
register 43-4 of the printer. The command is used for printing, as shown in Fig, 41. A response to this command is 
written by the printer inlo a response register 43-2 of the image providing device. The response includes mformat.on 
indicating whether or not the command has been properly executed, a return value to the command and the like. Pnnl 
is data sent from the image providing device to the printer is written into a data register 43-6 of the printer Format infor- 
mation sent from the image providing device to the printer is written as a format frame into a format register 43-7 of 

the P[£ 1 ^ ^ e constmclion Qt lhe format re gj St er 43-7. The format register 43-7 includes a read only register 

INQUIRY 44-1 for inquiry and a read/write register CONTROL/STATUS 44-2 for setting and information acquisition. 
The registers INQUIRY 44-1 and the CONTROLySTATUS 44-2 comprise register groups of the same structure. That 
is the INQUIRY 44-1 has registers 44-3 to 44-7, while the CONTROUSTATUS 44-2 has registers 44-9 to 44-13. 

More specifically, the format register group includes the registers 44-3 and the 44-4 (44-9 and 44-10) constituting 
a print common register group, and the registers 44-5 to 44-7 (44-11 to 44-13) constituting a printer format register 

9r ° U The common register group, which is a group of registers common to all the data formats, has the register GLOBAL 
44-3 (44-9) common to all the printers and the register LOCAL 44-4 (44-10) unique to each printer. 

The printer format register group is a group of n registers unique to the respective data formats, i.e., the register 
1ormat[1] 44-5 (44-11) to the register format[n] 44-7 (44-13). The registers 1ormat[1] to formalin] correspond to data 
formats to be described later. One of the printer format register group is assigned to each installed data format. 

Note that the address of each format register is provided to the image providing device as a response to a command 
for setting a data format. 

Fig 36 shows the detailed construction of the status register 44-8 of the common register group. The status register 
44-8 comprises a 32-bit common status register 45-1 holding a status common to the respective vendor printers and 
a 32-bit vendor specific status register 45-2 holding a status defined by each vendor Further, the extension of the 
35 vendor specific status register 45-2 is defined as follows, by a v flag (vendor status available flag) at the 31th bit of the 
common status register 45-1 : 
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v flag: *0" = not available 
"1* = available 

40 

Further, information held in the common status register 45-1 is as follows: 

error. warning: status of error, warning and the like 

paper state: status on print sheet 

45 print state: status on printing situation 

Fig 37 shows the details of information held in the register GLOBAL 44-3 (44-9) of the common register group. 
The register GLOBAL 44-3 (44-9) holds information common to all the printers having the DPP (Direct Print Protocol), 
i e information which does no1 differ in printer type. Fig. 37 shows an example of the information, including media- 
£0 type 46-1 indicative of the type of print medium, paper-size 46-2 indicative of a print sheet size, page-margin 46-3 
indicative of a page margin value, page-length 46-4 indicative of a page length, page-offset 46-5 indicative of page 
offset, print-unit 46-6 indicative of printer unit information, color-type 46-7 indicative of the color type of printer, bit-order 
46-8 indicative ol the bit order of data, and the like. 

Fig 38 shows the details of information held in the register LOCAL 44-4 (44-10) of the common register group. 
£5 The register LOCAL 44-4 (44-10) holds information unique to each of the printers having the DPP protocol, i.e.. infor- 
mation which differs in printer type. Fig. 38 shows an example of the information, including paper 47-1 indicative of the 
type of print sheet of a printer, CMS 47-2 indicative of a color matching method, ink 47-3 indicative of ink type of the 
printer, e.g., an ink-jet printer 
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Fig 39 shows Ihe details of information held in the register formalp) 44-5. In Fig. 39, information on EXIF (Ex- 
changeable Image File Format) as-one image data format is held. The information includes inX-rate 4B-1 indicative o1 
the rate of X^ireclional input, inY-rale 48-2 indicative of the rate of Y^iirectional input, oulX-rate 46-3 indicative of the 
rate ol X-directional output, and outY-rate 48-4 indicative of the rale of Y-directbnal output. In th.s case, printing is 
£ performed by enlarging/reducing given EXIF image data in the XY directions in accordance with the respective contents 
of the register. 

Fig 40 shows the details of information held in the register tormat(2) 44-6. In Fig. 40, information on Raw RGB as 
one image lormat is held. The Raw RGB format has a structure to represent each pixel by R (red), G (green) and B 
(blue) data. The information includes inX-rate 49-1 indicative of the rate of X-directional input. inY-rate 49-2 indicative 

w of the rate of Y-directional input, outX-rate 49-3 indicative of the rate of X-directional output, outY-rate 49-4 indicative 
of the rate of Y-directional output, XY-size 49-5 indicative of an X Y-directional lixed pixel size, bit-pixel 49-6 indicative 
of the number ol bits per pixel, X-size 49-7 indicative of the number of pixels in the X direction. Y-size 49-8 indurative 
of the number ol pixels in the Y direction, plane 49-9 indicative of the number of color planes, X-resolution 49-10 
indicative ol X-directional resolution, Y-resolulion 49-11 indicative of Y-directional resolution, pixel-formal 49-12 indic- 

15 ative of pixel type, and the like. In this case, printing is performed by enlarging/reducing given Raw RGB lormat .mage 
data and/or changing the resolutions in the XY directions in accordance with the respective contents of the register, 
further, processing the image data based on image size information and the like. 

Fig 41 shows commands and responses to the commands. The commands are classified based on several types, 
i e "status" type commands relating to status, "control' type commands for printer control, -block/buffer" type com- 

20 mands for data transfer setting, -channel" type commands for channel setting, 'transfer" type commands relating to a 
transfer method, -format' type commands relating to format setting, 'login* type commands relating to log-in, 'data 
type commands relating to data transfer, and the like. Note that the log-in. "login' type commands as aforesaid, and a 
command Login, a response Login Response, a command Logout and a response LogoulResponse described laler 
are unrelated to the LOGIN protocol as aforementioned. 

25 More specifically, the 'status" type commands include a command GetStatus to obtain the status of a printer and 

its response GetStatusResponse 50-1 and the like. 

The "control" type commands include a command PrintResetto reset the printer and its response Pr.ntResetRe- 
sponse 50-2 a command PrintStart to instruct to start printing and its response PrintStartResponse 50-3, a command 
PrintStop to instruct to stop printing and its response PrintSlopResponse 50-4, a command InsertPaper to instruct to 

30 supply a print sheet and its response InsertPaperResponse 50-5, a command EjectPaper to instruct to d.scharge a 
print sheet and its response EjectPaperResponse 50-6, a command CopyStart to instruct to start copying image data 
and its response CopyStartResponse 50-7, a command CopyEnd to instruct to terminate copying image data and its 
response CopyEndResponse 50-8, and the like. 

The 'block/buffer' type commands include a command BlockSize to designate a block size and its response Block- 
35 SizeResponse 50-9, a command BiockAddress to designate a block address and its response BlockAdressResponse 
50-10 a command FreeBlock to obtain the number of available blocks and its response Free Bloc kResponse 50-11 , a 
command WrileBlocks to instruct to write data into blocks and its response WriteBlocksResponse 50-12. a command 
BuflerConfig to designate buffer information and its response BufferConfigResponse 50-1 3, a command SetBuffer to 
designale to start obtaining data from buffer and its response SetBufferResponse 50-14, and the like. 

40 The 'channel' type commands include a command OpenChannel to open a channel and its response OpenCnan- 

nelResponse 50-15, a command CloseChannel to close the channel and its response CloseChannelResponse 50-16, 

and the like. t ju . , . # 

The "transfer" type commands include a command TransferMethod to designate a data transfer method and its 

response TransferMethodResponse 50-17 and the like. 
45 The 'format' type commands include a command SetFormat to set a format and its response SetFormatResponse 

50-18 and the like. _ n 
The "login- type commands include a command Login to perform log-in and its response LogmResponse 50-19, 

a command Logout to perform log-out and its response LogoulResponse 50-20, a command Reconnect to perform 

reconnection and its response ReconnectResponse 50-21 , and the like. 
so These commands are written into a command frame. 

Further the 'data' type commands include commands WriteBlock 50-22 and WriteBuffer 50-23 to write data, a 

command PullBuffer 50-24 to read data, and the like. These commands are written/read with respect to a data frame, 

and there have no responses corresponding to these commands. 

The image providing device sets a value corresponding to each of the various commands as shown in Fig. 41 at 
55 the operation code (opcode), and writes th e command into the command register 43-4 of the printer. Thus, the command 

is executed by the printer. The response to the command has the same value as that of the command.. The pr.nter sels 

the response at the operation code of the response frame as shown in Fig. 32, and writes the frame into the response 

register 43-2 of the image providing device. By the response, the image providing device receives the result of execution 
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0< ^Fir^Thows the image data lormals supported by the DPP protocol. The printer must support Raw image data 
of at least one ot these formats. Further, the printer can support other plural lormats as optional formats. 

Fig 43 shows Ihe flow of format setting processing. First, the image providing device sends the command Set- 
Format (I NQU I RY) to the printer at step S500. and the printer returns the SetFormalResponse al step S501 . The rmage 
providing device obtains the address of the INQUIRY register of the printer by the returned response. 

Next the image providing device sends the command SetFormal (CONTROL/STATUS) to the printer at step S502, 
and the printer returns the SetFormalResponse at step S503. The image providing device obtains the address of the 
CONTROL/STATUS register of the printer by the returned response. 

The image providing device reads the INQUIRY regisler of the primer at steps S504-1 to S504-m and obtains the 
format supported by the printer and sel items of Ihe format. Next, the image providing device reads Ihe STATUS/ 
CONTROL register of the printer at steps S505-1 to S505-n. obtains the set values of the format, then writes data into 
the STATUS/CONTROL register of the printer, thus sets the format. 

The data transfer in the DPP protocol uses the following two packets. 

Control command packet for flow control 
Packet for data transmission 

In the present embodiment, the following five types of data transfer methods are used in accordance with the 
difference among data transmission methods and flow conirols. In any melhod. control commands for the flow control 
are based on ihe FCP protocol. However, The control commands are not limitted to the FCP protocol. 

Transfer method 1 : Response model 

Transfer method 2: Simplified response model 

ss Transfer method 3: PUSH large butler model 

Transfer method 4: PULL buffer model 

Transfer method 5: Isochronous model 

In actual transfer, one of the above methods is selected and set in a procedure similar to the lormat setting pro- 
30 cedure as shown in Fig. 43. Note that as shown in Fig. 44. the command TransterMethod and the response Transf er- 

MethodResponse are employed. . . _ _ llrr( ,_ tlu 

Fiq 44 shows the flow of data-transfer method setting processing. The image providing device obtains a currently 
available data transfer method of the printer by the command TransterMethod and the response TransferMetho- 
dResponse in Ihe command type INQUIRY (steps S600-1 and S600-2). and obtains and sels a data transfer method 
currently set at the printer, by the command TransterMethod and the response TransferMethodResponse of the com- 
mand type CONTROL/STATUS (steps S600-3 and S600-4). COD 
In any of the above five type of transfer methods, the control commands for flow control are based on the FCP 
proiocol as a protocol for controlling a device on the 1394 serial bus. The transfer ot control command by the FCP 
protocol is always performed by an asynchronous write transaction, in both transmission and response. 
ao Fiq 45 shows a register map ot registers necessary for the transfer method 1 and the transfer method 2 in address 

space of the 1394 serial bus. In the present embodiment, a node on the controller side is the image providing dev IC e 
(controller in the FCP protocol), and a node on the controlled side is the printer (target in the FCP proiocol). 

Both image providing device and printer have a command register (601-1 and 601-7) with offset of 512 bytes from 
•OxOBOO" and a response register (601-2 and 601-8) with offset of 512 bytes from -OxODOO" in the register space. 
as These reqislers are based on the FCP protocol and the AV/C commands. 

The flow control is made by writing the command frame 601-4 and the response frame 601-5 into the command 
register (601-1 and 601-7) and the response register (601-2 and 601-8). respectively. Further, for print data transfer 
a dedicated data frame is defined. That is. a data register (601-3 and 601-9) for a block size is provided from offset 
•0x3000" in the register space, and print data is transferred by writing a data frame 601 -6 Into the data register (601-3 
so and 601 -9). Note that the block size is 51 2 bytes, for example. 

Fiq 46 shows a data packel frame comprising a data header 602-1 , a data payload 602-2 and the like. 
Fiq 47 shows the structure of the data header 602-1. In the data header 602-1 , upper 8 bits are ass.gned to a 
block count area 603-1 , and lower 8 bits, to a future reserve area 603-2. The block count area 603-1 is internally used 
by the target (printer) to count the number of blocks transferred at one block transfer. Note that as the block count area 
55 603-1 has 8 bits, it takes a value "0" to "255\ . . 

Fiq 48 shows data packet frame processing in Ihe printer in block transfer. A data packet rece.ved by the printer 
is first written into a data register 604-1 ol the printer. The printer has butters (604-2 to 604-5) of the same size ol that 
of the data packet. The data packet written in the data register 604-1 is sequentially moved to these buffers (604-2 to 
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604-5). No,o that the number of the data butters is preterably 255. the maximum block count value, but it, iray bo a 
value ess than 255. The respective butters correspond to block count values. A dala packet when the block count 
la Z is is stored into a buffer o, BlocktO]; and a data packet when the block count value m ; "1 ' .s sto rec ^ 
of Block|1]. The data header 602-1 is removed Irom the data packets stored in the butlers (604-2 to 604-5), and the 
data packets are developed in a memory space 604-6 ol the printer. 

[Transfer Method 1 ] 

The transfer method 1 as the response model defines a data packet frame for data transmission, provides a data 
register, performs flow control by control commands, while transfers prinl dala by a write transaction. 

9 Fig 49 shows commands and responses FreeBlock in the transfer method 1 . In the transfer method 1 p no to 
data transfer, the image providing device uses the commands and responses FreeBlock to obtain .nformafon md.cat.ng 
the number of data packets to be transferred. nrin 1or 

The image providing device transfers the FreeBlock command by a write transact™ (step S605-1 , and the printer 
returns JnACK packet indicative of the acknowtedgment of the transaction (step S605-2). The pnnte r ret urns the 
FreeB^kRespoL to notify a FreeB.ockCount (step S605-3) which is the number of currently a-^^- 
the image providing device returns an ACK packet indicative of the acknowledgment of the transact on ( Jep i BE 05-4)^ 

Fiq 50 shows the flow of data transfer in the transfer method 1 . The image proving dev.ee logs in the printer by 
the command and response Login ol the DPP protocol (steps S606-1 and S606-2), and sets a format to be used for 
c^a tranter by using the aboveWibed format register group (step S606-3). Thereafter, the image proving device 
^rlTS^nnl by the command and response OpenChanne, (steps S606-4 and SK*5). Next d^ .rans er 
^ started, and print data is transferred in the data packet format as shown in Fig. 46 Further, the packet ran fens 
performed in correspondence with the number of blocks the same as the number of data buffers on the printer side, 
as shown by references 604-2 to 604-5 in Fig. 48. as one cycle. 

in the transfer melhod 1. the print data is transferred as follows. The image providing dev,ce obtains the Free- 
BlcckCoun oUhe printer by the Command and response FreeBlock (steps S606-6 
transfers data packets of the same number as that of the FreeBlockCount. by the command Wr.teBloc 
Note that the command WriteBlock is used tor transferring print data packets from the data reg.ster 60 -3of the image 
providing device to the data register 601 -9 of the printer. Note that there is no <^°™°° 0 ™l^Z° fnte ^nTSa 
WriteBlock. and the printer returns an ACK packet to confirm that the data packets have been stored into the data 

regiS ^en°b.o 9 c k transfer is performed by repeating packet transfer, with the commands WriteBlock ^n™™"*"' 
of the FreeBlockCount and ACK packets corresponding to the commands until all the series of P" n JJ^ J™ *™ 
outputted from the image providing device, and between the respective block transfers, the FreeBlockCount of the 
printer is obtained by the command and response FreeBlock. , ,u„ i™;„ rh »n^i hv the 

When the print data transfer has been compleled. the image providing dev.ee closes the logic channel by the 
command and response CloseChannel (steps S606-10 and S606-11). and logs out from the printer by the command 
and response Logout of the DPP protocol (steps 5606-12 and S606-13). 

[Transfer Method 2] 

The transler method 2 as the simplified response model performs data transfer in the same procedure as that of 
the transfer method 1 except the melhod to obtain the FreeBlockCount. 

Fig 51 shows the flow of data transler in the transfer method 2. The image proving dev.ee logs in the printer by 
the command and response Login ot the DPP protocol (steps S607-1 and S507-2). and sets a format to be used tor 
dataTr^ter by using the above^escribed forma, register group (step S607-3) ^^^^S^SZf 
opens a logic channel by the command and response OpenChannel (steps S607-4 and S607-S£ " e *-*f*™* *l 
fs started, and print data is transferred in the data packet format as shown in Fig. 46. Further, the packet ransfer s 
performed in correspondence with the number of blocks the same as the number of data butters on the printer side, 
as shown by references 604-2 to 604-5 in Fig. 43. as one cycle. 

in the transfer method 2. the print data is transferred as follows. The .mage providing dev.ee obta.ns the Free 
BlockCount of the printer ol the printer by the command WriteBlocks and response WrileBlo = kRes ^ S ,^ 
and S607-7). Note that the response at step S607-7 is ot the INTERIM type for performing theacqu«rt »n o Mhe Ra e- 
BlockCount only by the response from the primer side. The image prov.dmg device sequentially transfers data packets 
o The same number as the obtained FreeBlockCount. by the command WriteBlock (step S607-8). and he printer 
returns the above-described ACK packet (607-9). Then, block transler is performed by. repeating packet transfer by 
the commands WriteBlock of the same number as the FreeBlockCount and ACK packets ™ I ^"*. X °*Z£Z 
mands until all the series ol print data has been outputted from the image prov.d.ng device. Note that at the second 
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cycle and the subsequent cycles in the block transfer, the FrccBlockCount is notitied to the image providing device by 
the WriteBlocksResponse from the printer, at the end of each block transler cycle (step S607-1 0). The WriteBlocksRe- 
sponse is of the CONTINUE type used for continuing the acquisition of the FreeBtockCount only by the response from 
the printer. 

When the print data transfer has been completed, the image providing device closes the logic channel by the 
command and response CloseChannel (steps S607-11 and S607-12), and logs out from the printer by the command 
and response Logout of the DPP protocol (steps S607-13 and S607-14), 

[Method to Obtain FreeBlockCount] 



Hereinbelow, the method to obtain the FreeBlockCount, which is the difference between the transfer method 1 
and the transfer method 2, will be described in detail. 

Fig 52 shows the commands and responses FreeBlock in the transfer method 1 at steps S606-6 and S606-7, in 
detail, including the ACK packets of the write transaction omitted in Fig. 50. In this case, both initiator device (image 
75 providing device) and the target device (printer) perform processing of the link layer and transaction layer at a relatively 
low speed. 

When the image providing device writes the command FreeBlock into the command register by a wrrte transaction 
(step S608-1), the above -de scribed ACK packet indicative of "pending" is returned from the link layer of the printer 
(step S608-2) ' Next, the image providing device sends a command FreeBlock with no data (step S608-3). and receives 
20 an ACK packet indicative of 'complete' from the printer (step S608-4). Thus, one write transaction ends. 

Next, the printer returns the FreeBlockResponse. Similar to the command FreeBlock at step S608-1 , the Free- 
BlockResponse is written as a'response including the FreeBlockCount into the response register (step S608-5). An 
ACK packet indicative of 'pending" is returned from the link layer of the image providing device (step S606-6). Then, 
the printer sends the FreeBlockResponse with no data (step S608-7), and receives an ACK packet indicative of "com- 
25 plete" (step S608-8). Thus, one write transaction ends. 

On the other hand, in the transfer method 2, only the FreeBlockResponse from the printer is used to obtain the 
FreeBlockCount at the second and the subsequent cycles in the print data block transfer. Accordingly, the FreeBlock- 
Count is obtained only by the operation at steps S608-5 to S60B-8. 

The acquisition of the FreeBlockCount is necessary at each cycle of block transfer. Accordingly, in the transfer 
30 method 2, the number of packets transferred on the bus can be less than that in the transfer method 1. 

Fig. 53 shows the commands WriteBlock in the transfer method 1 and the transfer method 2 in detaii. As the 
command WriteBlock requires no response, commands in this procedure are sent in the order, the WriteBlock (step 
S609-1), an ACK packet indicative of "pending" (step S609-2). the WriteBlock with no data (step S609-3) and an ACK 
packet indicative of "complete" (step S609-4). The length of the procedure is the half of that in the case where commands 
35 and responses are transferred. This performs data transfer at a relatively high speed even if the processings in the 
link layer and the transaction layer are performed at a relatively slow speed. 

Fig. 54 shows the command WriteBlock in the transfer method 1 and the transfer method 2 in detail, in a case 
where the processings in the link layer and the transaction layer are performed at a sufficiently high speed. In this case, 
commands in this procedure are sent in the order, the WriteBlock (step S610-1), and an ACK packet indicative of 
ao 'complete" (step S610-2). This performs more efficient data transfer. 

Fig 55 shows the flow of WriteBlock error processing upon occurrence of bus reset. In this case, the bus reset 
occurs at transfer of n-th (= 0-255) packet at one block transfer cycle. In a write transaction, a failure of data packet 
transfer is indicated by an ACK packet, however, error upon bus reset cannot be detected. Then, in the present em- 
bodiment error processing is performed in the following procedure. That is, in a case where the FreeBlockCount is 
as obtained (step S611-1). then the WriteBlock is sent n times (step S611-2 to S611-6). if bus reset occurs at this time 
(step S611-7). the image providing device again sends the WriteBlock[n] immediately before the bus reset (step 
S611-8), and thereafter, continues the processing (steps S611-9 to S611-14). 

[Transfer Method 3] 

50 

Fig. 56 shows the construction of command registers, response registers and data registers of the image providing 
device and the printer, in the PUSH large buffer model. 

The commands and responses between the image providing device and the printer based on the FCP protocol 
are executed by operation of writing a command frame 65-7, as command request data, from a command register 65-1 
55 of the image providing device into a command register 65-4 of the printer, and operation of writing a response frame 
65-8, as response data, from a response register 65-5 of the printer into a response regisler 65-2 of the image providing 
device. 

Further, different from the FCP protocol, a data frame 65-9 is used in one directional operation of writing image 
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data from a data register 65-3 ol the image providing device inlo a data regisler 65-6 o1 the printer by using a write 

transaction. • • . 

Fig 57 shows the flow of operation ol the PUSH buffer model between the image providing device and the printer. 

Note that the commands Login, Logout, OpenChannel and CloseChannel and format setting are similar to those 
5 in the above-described transfer method 1, therefore, detailed explanations of the commands and the format selling 
will be omitted. 

In Fig 57. the image providing device inquires about the buffer area of the printer by Ihe command BufferConfig 
indicating 'INQUIRY" (step S1 701 ). The printer returns the butter size and buffer address by the BufferConf igResponse 

(stepS 1702). . ^. ^ ^ , . 

io Next the image providing device sets the buffer size and the buffer address of the printer into which data is written, 

by the command BufferConfig indicating "CONTROL' (step S1703). The printer returns the BufferConf igResponse 
indicating that the setting has been completed (step S1704). 

Next the image providing device notifies the printer that data transfer is io be started, by using the command 
SetBuffer indicating "NOTIFY* (step S1705). The printer returns the "INTERIM" SetBufferResponse indicating that the 

75 printer is prepared for the present to receive the data (step SI 706), to let the image providing device start data transfer. 
Then, the printer notifies Ihe image providing device that the data transfer Io the initially set buffer area has been 
completed, by using the SetBufferResponse indicating "CONTINUE" (step S1709). 

The command WriteButfer at step S1 707 indicates data frame writing by the image providing device. In this oper- 
ation data is sequentially written into the buffer address set in the printer. 

so A response WriteTransactionResponse at step SI 708 indicates a response packet upon isochronous transfer of 

data frame As described above, if the data input speed of the printer is sufficiently high, the processing can be com- 
pleted by using an acknowledgment of one write transaction, however, if data input takes time, independent responses 
occur as a split transaction. 

Step S1710 indicates processing of transferring a plurality of data frames. That is, the data is transferred by a 
25 series of transactions to an area having the buffer size set by using the command BufferConfig. The data transfer 
method using a series of transactions is called a 'PUSH data transfer method" or abbreviated to a "PUSH method". 

Fig. 58 shows the structure of a data packet in the data frame. As the data can be written by directly addressing 
the buffer of the printer, a data packet 67-1 does not include a header and the like. 

Fia 59 shows the relation between Ihe data register and the buffer of the printer. Data written in a data regisler 
30 68-1 is directly written into the address of a memory space 68-2 of the printer, designated by "Buffer Address' determ.ned 
by an offset "Destination.Offsef. As the offset value is incremented by a data length indicated by "Data_Length", the 
data is continuously written within the area indicated by "BufferSize" by repeatedly writing the data into the series of 
buffer addresses. 

35 [Transfer Method 4] 

Fig. 60 shows the construction of the command registers, the response registers and the data registers of the 
image providing device and the printer, in the PULL buffer model. 

The commands and responses between the image providing device and the printer, based on the FCP protocol, 
ao are executed by operation of writing a command frame 69-7, as command request data, from a command register 69-1 
of the image providing device into a command register 69-4 of the printer, and operation of writing a response frame 
69-8, as response data, from a response register 69-5 of the printer into a response register 69-2 of the image providing 
device 

Further, different from the FCP protocol, a data frame 69-9 is used in one -directional operation of reading image 
45 data from a data register 69-3 of the image providing device into a data register 69-6 of the printer by using a read 
transaction. 

Fig 61 shows the flow of operation of the PULL buffer model between the image providing devtce and the printer. 
Note that the commands Login, Logout, OpenChannel and CloseChannel and format setting are similar to those in the 
above-described transfer method 1, therefore, detailed explanations of the commands and responses BufferConfig 
so and SetBuffer (steps S1711 to S1714), which are the same as those in the above-described transfer method 3, will be 

omitted. . . 

In Fig 61 the image providing device notifies the printer that data transfer can be started by using the command 
SetBuffer indicating "NOTIFY" (stepS1715). The printer returns the "INTERIM' SetBufferResponse indicating that the 
printer is prepared to receive data (step S1 716) for the present, and let the image providing device start data transfer. 
55 Then, the printer notifies the image providing device that data transfer into the initially set buffer area has been com- 
pleted by using the SetBufferResponse indicating "CONTINUE' (step S1719). 

The printer requires a read transaction by a command PullButferRequest (step S1717). Then the image providing 
device transfers data by a PullButferResponse packet (step Si 718), thus data is sequentially written into the buffer 
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address set in the printer. . 

Step S1720 indicates processing o1 transferring a plurality of data frames. That is, the data is transferred by a 
series ot read transactions to the area having the bufler size set by using the command BufferConf ig. The data transfer 
method using a series of transactions is called a "PUSH data transfer method' or abbreviated to a 'PUSH method'. 

Fig 62 shows the relation between the data register and the buffer of the image providing device. Data is read 
from a memory space 72-2 of the image providing device designated by 'BufterAddress" determined by an offset 
•Destination_Offsef set in the data register 71-1. As the offset value is incremented by a data length indicated by 
•DataJ-ength', the data is continuously read from the area indicated by "BufferSize" by repeatedly wrrtmg the data 
into the series of buffer addresses. 

[Transfer Method 5] 

In the transfer method 5 as the isochronous model, the print data transfer by using the asynchronous transaction 
in the above-described transfer method 1 is replaced with print data transfer by using an isochronous transaction. Note 
is that the structure of a data packet is the same as that shown in Figs. 46 and 47. Further, the data packet frame process- 
ing in the printer upon block transfer is the same as that in Fig. 48. 

Note that according to the present transfer method, data transfer can be made at predetermined time by using an 
isochronous write transaction. 

Further in the block transfer, if an error occurs upon transferring print data for one page at once, it takes a long 
20 time to re-transfer the print data for one page. However, rf print data is transferred in more line block units, e.g., print- 
band units of an ink-jet printer, print data re-transfer due to the occurrence of error can be efficiently performed. 

Fig 63 shows command registers and response registers for flow control. The image providing device writes a 
command frame into a command register 75-3 of the printer by an asynchronous write transaction. The printer writes 
a response frame to the command into a response register 75-2 of the image providing device by an asynchronous 

25 write transaction. . 

Fig 64 shows the flow of print processing. First, similar to the above<Jescribed transfer method 1, the image 
providing device sends the command Login to the printer (step S507). The printer returns the LoginResponse (step 
S50B), thus connection is established. 

Next similar to the above-described transfer method 1 , the image providing device performs format setting (step 
30 S509), and sends the command OpenChannel to the printer (step S510). The printer returns the OpenChannelRe- 
sponse (step S511 ), thus a logic channel is opened. 

Then the image providing device sends the command FreeBlock to the printer (step S512). The printer returns 
the FreeBlockResponse (step S51 3). The FreeBlockResponse includes the number of FreeBlock and ErrorStatus. The 
number of FreeBlock is the number of block buffers ensured in block units in the memory space of the pnnter. The 
35 ErrorStatus is used to notify the image providing device of error information in previous block transfer. Note that the 
printer always returns -normal" as the ErrorStatus to the first command FreeBlock after the logic channel has been 
opened 

Then, the image providing device block-transfers print data by an isochronous transaction (step S514). At this 
time the Image providing device sends data packets of the number corresponding to the FreeBlockCount. 
AO Next the image providing device sends the command FreeBlock to the printer (step S51 5). The printer returns the 

FreeBlockResponse (step S51 6). If the ErrorStatus of the response indicates 'abnormal-, i.e., if an error has occurred 
at the previous block transfer, the image providing device sends the data transferred at step S514 again (step S517). 
Thereafter the processing at steps S515 to S517 is repeated until the data transfer has been normally completed. 
Further, if the ErrorStatus indicates 'normal", the image providing device sends data packets of the number indicated 
as by the FreeBlockCount included in the FreeBlockResponse (step S517). 

Note that the printer determines whether or not an error has occurred by referring to the block count of the header 
in transferred data (Fig. 64). Further, rf the FreeBlockCount is greater than the number o1 blocks of data to be transferred, 
the image providing device sends dummy packets of a number corresponding to the excessive blocks. 

Then, data transfer by an isochronous transaction is repeated until all the series of print data have been outputted 
so from the image providing device. 

When the data transfer has been completed, similar to the above -described transfer method 1 , the image providing 
device closes the logic channel by the command and response CloseChannel (steps S518a and S519), and logs out 
1rom the printer by the command and response Logout of the DPP protocol (steps S520 and S521 ). 

As described above, according to the present embodiment, the image providing device and the printer are directly 
55 connected by using the 1 394 serial bus or the like, and image data is directly sent from the image providing devtce to 
the printer, so that the printer prints an image based on the image data. 

Further, as control commands and print data are separated, the embodiment provides an efficient data transfer 
methods in the 1394 serial bus or the like. 
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Further the embodiment provides a data transfer method which recovers a transfer error in Ihe 1394 serial bus. 

Further, the embodiment provides a data transfer method in which determination whether or not data can be written 
into the register area is unnecessitated by notification of the number of available blocks of a reg.ster area lor data 
transfer and .he overhead necessary for the determination is removed. Further, the embodiment prov.de an efficient 
5 data transfer method since as data for the notified number of available blocks is transmitted and received. 

Further, according to the embodiment, a data transfer method appropriate to a transfer destination device can be 

selected from a plurality of data transfer methods. h.,» 

Further the embodiment provides a data transfer method which avoids degradation of transfer efficiency due to 
command transmission upon data transfer from a host device to a target device, by only a comma ,nd ,n structing 
io to start data transmission and a response to the command, i.e., transmitting no command after ihe start of the data 

'^"F'urther, the embodiment provides a data transfer method based on the PUSH method or PULL method upon data 

Iranster between a host device and a target device. hr „„„, , c 

Further the embodiment provides a data transfer method which performs .sochronous transfer and asynchronous 
is transfer in the same transfer procedure upon data transfer between a host device and a target device 

Further, the embodiment provides a data Iranster method in which, when a transfer error occurs at pertain part 
of data in isochronous transfer, performs re-transfer the part of data where transfer the error has occurred, upon data 
transfer between a host device and a target device. 

Further, the embodiment provides a data transfer method which performs proper data transfer even .f bus reset 
20 occurs in data transfer between a hosl device and a target device. 

Further, a peripheral device such as a printer which utilizes the above data transfer methods can be provided. 

[Modification of First Embodiment] 

Note that the above embodiment has been described in a case where a network is constructed by using the IEEE 
1 394 serial bus, however, the present invention is not limited to the 1 394 serial bus. For example the . presert ^ invention 
is applicable to a network constructed by using an arbitrary serial interface such as a Universal Sen a I Bus (US* . 

in the above-described embodiment, commands and responses to the commands based on the TCP protocol are 
«nnk*«i and information is set at the response and notified to the host device. However, a method of mapping a 
30 registers a memory as the characteristic feature of the IEEE 1 394 memory bus model can be cons.oereo. 

in this case, a command is executed by writing command data into a command register assigned to a speed c 
address of the memory. Similarly, a response is indicated by reading data at a response register assigned to a specific 

addr ^co°rd!ngly m8 w^en the target device recognizes that a command has written into a command register, the target 
35 device executes the command, and writes the result of the execution of the command and "tomator, a ™«pon se 
register The host device which has written the command into the command register reads the response reg.ster of 
ihe target device and obtains the result of the execution of Ihe command and information 
Thus, the present invention can be realized by using registers in the memory bus model. 

In the above-described embodiment, discussing examples which have a taget dev.ee as a printer. However the 
<o target device of the present invention is not limitted to the printer. That is. some dev.ee recording .mage data such as 
a display apparatus and a storage apparatus applies to the target device of the present .nven ton. 

in this runner, theabove embodiment and modification provide a datatransmiss.cn apparatus, system and method 
and an imaTe processing apparatus, appropriate to a case where a host device and a target dev.ee are d.rectly con- 
nected by using the 1 394 serial bus or the like, the host device directly sends image data to the target device, so that 
45 the tarqet device processes the image data. m „,^^ 3n n 

Further the above embodiment and modification provide a data transmission apparatus, system and method and 
an image processing apparatus which separate control commands from data and attain high transit -et c.enc> ,. 

Further the above embodiment and modification provide a data transmission apparatus, syslem and method and 
an image processing apparatus which reduce overhead necessary for determining whether or not data can be written 

so into a data transfer area. ^ , m ^^^j „ or j 

Further, the above embodiment and modification provide a data transmiss.on apparatus, system and method and 
image processing apparatus which transmit/receive data of an amount, corresponding tothe number of available blocks 

of a data transfer area. 

ss [Second Embodiment] 

In a case where image data is transferred in accordance with the IEEE 1394 standards, the direction of the data 
which flows on the network is not limited to one direction. That is, the relation between the dev.ee that provides ,mage 
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data and the device that receives the provided image data can be applied to various devices such as a host computer 
and a printer a digital camera and a host computer, and a scanner and a printer. 

Further in the respective cases of the above-described embodiment, the controller of flow control may be the 
source device side which provides image data and may be the destination device side which recerves the prov.ded 

^ NeJ* a second embodiment will be described below as an example where the controller of flow control changes. 
In this example, a scanner transfers data to a host computer. Note that the basic flow control has been made in the 
above -described transfer method 1. , . 

Accordingly the host computer performs processing similar to the data packet frame process«ng .n the printer upon 
b.cS tmnLr as shown in Fig. 48. Further, the second embodiment is applicabie to the above-desenbed transfer 

" letl |n1he 2 pTesent embodiment, the data transfer system for the image transfer has the following functions: 

(1 ) Reverse command: a host computer logs in an image providing device such as a scanner and a digital camera, 
and changes the controller of flow control by a reverse command. As a result, the image providing dev.ee opens 
a channel, and performs dala transfer. 

(2) Data request command: the host computer is the controller of flow control. The image providing device transfers 
data to the host computer in accordance with a data request command. 

(3) Log-in from scanner: the image providing device logs in the host computer, and performs data transfer as the 
controller of flow control. Before the image providing device sends image data, it notifies the host computer of the 
data transfer using a data transmission command. 

Hereinbelow the above functions will be respectively described in detail with reference to the drawings^ Note that 
in the following description, data transfer is performed between a host computer and a scanner, however, the present 
invention is not limited to this case, but data transfer may be performed between, e.g.. an .mage processing dev.ee .n 
place of the host computer and an image providing device such as a scanner. _ oer ^ n Hinn to 

Further Fio. 65 shows commands and responses to the commands in the second embodiment, corresponding to 
those in to Fig^t, except a "block/buffer" command FreeBlockNotify and its response FreeBlockNotifyResponse 
50-25 a "transfer- command Reverse and its response ReverseResponse 50-26. and "transfer- a command PutData 
command and its response PutDataResponse 50-27, added to the commands and responses in Fig. 41. 

[Reverse Command] 

Fiq 66 shows an example where a host computer logs in a scanner and changes the controller of flow control by 
using the Reverse command. The scanner which is a node of the logged-in side issues the OpenChannel command 
to open a channel, and performs image data transfer as the controller of the flow control. 

The host computer logs in the scanner by the Login command of the d.rect printer prot ocol (DPP > ^ te P S80 °; ^ 
The scanner returns a connect ID (ConnectID) in the LoginResponse 1o the command (step SBOO-2). The ConnectID 
is used by the scanner to manage connection to the scanner. n „„„„„ e „ , ho 

Next the host computer sends the Reverse command to the scanner and receives a ReverseResponse to the 
command (steps SB00-3 and S800-4). This changes the controller of the flow control, and allows the scanner to open 
a data transfer channel and transfers data. „, h _H 1 

Then image data transfer is performed in a procedure (sleps S800-5 to S800-10) similar to the transfer method 1 

33 'whTn'lhe image data transfer has been completed, the scanner sends the CloseChannel command to the host 
computer and receives the CloseChannelResponse to the command, thus closes the logic channel (steps S800-11 
and SB00-12). The scanner sends the Reverse command to the host computer and receives the ^erseRes^se 
to the command (steps SB00-1 3 and SBOO-1 4). This changes the controller of the flow control again. The host compute 
sends thT DPP Logout command to the scanner and receives the LogoutResponse to the command, then logs out 
from the scanner (steps S800-15 and S800-16). 

[Data Request Command] 

Fig. 67 shows an example where the scanner transfers data to the host computer in accordance with a data request 
command issued Irom the host computer, as the controller ol flow control. ,^ 0 ™ mmanH 
in this case, the command-response direction does not change as in the above case using the Reverse command. 
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The difference from the transfer method 1 is the direction of image data transfer, and means tor determining the transfer 
direction is provided. By this means, a node which has logged in a target and opened a logic channel by the Open- 
Channel command can be the receiver of image data. 

The procedure from log-in to the opening of logic channel (steps SB01-1 to S80V5) is the same as that in the 
s transfer method 1 as shown in Fig. 50. When the logic channel has been opened, the host computer becomes the 
receiver of image data by the data request command RequireData and its response RequireDataResponse (steps 
S801-6 and S801-7), thus determining the data transfer direction.. Thereafter, image data transfer is performed as 
follows. 

The host computer notifies the scanner of the number of available blocks (FreeBlockCount) by the FreeBlockNotify 
70 command (step S801-B), and the scanner notifies the host computer of the size of remaining image data (Remainning- 
DataSize) in the FreeBlockNotrfyResponse to the command (step S801 -9). As the FreeBlockCount of the host computer 
is notified to the scanner, the scanner sends data packets of a number corresponding to the notified FreeBlockCount 
to the host computer (step S801-10). 

In this manner, the block transfer is made by repealing transfer of data packets of the number corresponding to 
75 the FreeBlockCount until all the series of image data have been transmitted from the scanner, and between respective 
block transfers, the FreeBlockCount of the host computer is obtained by the FreeBlockNotify and the FreeBkxkNoti- 
fyResponse. When all the series of image data have been transferred, the first FreeBlockNotify Response indicates 
that the data size of remaining image is zero (S801 -1 2), accordingly, the host computer obtains time to close the logic 
channel. 

20 The procedure after the completion of the image data transfer is the same as that in the transfer method 1 as 

shown in Fig. 50. The host computer closes the logic channel by the CloseChannel command and the CloseChannel- 
Response (steps S801-13 and S801-14), and logs out 1rom the scanner by the DPP Logout command and LogoutRe- 
sponse (steps S801-15 and S801-16). 

25 [Log-in from Scanner] 

Fig. 68 shows a procedure in a case where the scanner logs in the host computer and performs data transfer as 
the controller of flow control. 

In this case, the flow of the image data transfer is almost the same as that in the transfer method 1 . The difference 
30 irom the transfer method 1 is that before the scanner sends the image data, the scanner notifies the host computer by 
the data transmission command (PutData) that the image transfer is to be started (step S802-1), and the host computer 
returns the PutDataResponse to the command (step S802-2). 

in this manner, the second embodiment attains advantages similar to those of the first embodiment and its modi- 
fication, and further, enables a device having a bi-direction data transfer function, i.e., a device which has a function 
35 to receive data and a function to provide data, to perform data transfer in a desired direction. 

The present invention can be applied to a system constituted by a plurality of devices (e.g., host computer, interface, 
reader, printer) or to an apparatus comprising a single device (e.g., copy machine, facsimile). 

Further, the object of the present invention can be also achieved by providing a storage medium storing program 
codes for performing the aforesaid processes to a system or an apparatus, reading the program codes with a computer 
<o (e.g., CPU, MPU) of the system or apparatus from the storage medium, then executing the program. 

In this case, the program codes read from the storage medium realize the functions according to the embodiments, 
and the storage medium storing the program codes constitutes the invention. 

Further, the storage medium, such as a floppy disk, a hard disk, an optical disk, a magneto-optical disk, CD-ROM, 
CD-R, a magnetic tape, a non-volatile type memory card, and ROM can be used for providing the program codes. 
45 Furthermore, besides aforesaid functions according to the above embodiments are realized by executing the pro- 

gram codes which are read by a computer, the present invention includes a case where an OS (operating system) or 
the like working on the computer performs a part or entire processes in accordance with designations of the program 
codes and realizes functions according to the above embodiments. 

Furthermore, the present invention also includes a case where, after the program codes read from the storage 
so medium are written in a function expansion card which is inserted into the computer or in a memory provided in a 
function expansion unit which is connected to the computer, CPU or the like contained in the function expansion card 
or unit performs a part or entire process in accordance with designations of the program codes and realizes functions 
of the above embodiments. 

The present invention is not limited to the above embodiments and various changes and modifications can be 
55 made within the spirit and scope of the present invention. Therefore, to appraise the public of the scope of the present 
invention, the following claims are made. 
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Claims 
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1. A data transmission method tor a data transmission system which transfers data between devices connected by 
a serial bus, the data transler, started by tirst and second devices, perlormed on the basis of device information 
of the first and second devices provided in advance, wherein, in a case where the second device has a flow control 
function, an initiative of a flow control for the data transfer is moved from the first device to the second device in 
accordance with a command issued by the first device, and the initiative is returned to the first device when the 
data transfer is completed. 

2. The method according to claim 1, wherein a direction of transfer between the first and second devices when 
transferring commands and responses is reversed by the command. 

3. The method according to claim 1 , wherein a direction of the data transfer between the lirst and second devices is 
reversed by the command. 

4. The method according to claim 1 , wherein the data transfer is performed by sending data of an amount based on 
buffer information relating to a reception buffer, obtained by asynchronous bi-directional communication between 
the first and second devices. 

5. The method according to claim 1 , wherein the serial bus is a bus adapted to or based on the IEEE 1394-1995 
standards. 

6. The method according to claim 1, wherein the serial bus is a bus adapted to or based on Universal Serial Bus 
standards. 

7. The method according to claim 1 , wherein the second device provides image data. 

8. The method according to claim 1, wherein the second device has a function to form a visible image based on 
image data on a recording medium and a function to read an original image, and selects one of these functions. 

30 

9. The method according to claim 1 , wherein the first device processes received data. 

1 0. The method according to claim 1 , wherein the first device is a host computer. 
35 11. An image processing apparatus, comprising: 

communication means for performing communication with a target device by the data transfer method in claim 
1; and 

reception means for receiving image data from said target device via said communication means. 

AO 

12. An image processing apparatus, comprising: 

communication means for performing communication with a host device by the data transfer method in claim 
1; and 

A5 providing means for providing image data to said host device via said communication means. 

13. A data transmission apparatus connected to a serial bus, comprising: 

generation means for generating a command to reverse data transfer by a device connected to the serial bus; 
50 and 

transmission means for transmitting the generated command to said device. 

14. The apparatus according to claim 1 3. wherein flow control relating to the data transfer is reversed by the command. 

ss is. The apparatus according to claim 1 3. wherein a direction of transfer with a data providing device when transferring 
commands and responses is reversed by the command. 

1 6. The apparatus according 1o claim 1 3. wherein a direction o1 the data transfer wilh a dala providing device is reversed 
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by the command. 



17 The apparatus according to claim 1 3, wherein the data transfer is performed by sending data of an amount based 
on butter information relating to a reception buffer obtained by bi-directional communication with a data prov.dmg 
5 device. 

18. A data transmission apparatus connected lo a serial bus, comprising: 

reception means for receiving a command from a device connected to the serial bus; and 
w transfer means for reversing data transfer based on the command received by said reception means. 

19. The apparatus according to claim 18, wherein flow control relating tothe data transfer is reversed by the command. 

20. The apparatus according to claim 1 6, wherein a direction of transfer with a data providing device when transferring 
is commands and responses is reversed by the command. 

21 . The apparatus according to claim 1 8, wherein a di rection of the data transfer with a data providing device is reversed 
by the command. 

20 22 The apparatus according to claim 1 8, wherein the data transfer is performed by sending data of an amount based 
on buffer information relating to a reception buffer obtained by bi-directional communication with a data prodding 
device. 

23. A data transmission system for transferring data through a serial bus, comprising: 

issuance means for issuing a command to a first device connected to the serial bus; and 
control means for reversing data transfer by a second device connected to the serial bus, based on the com- 
mand issued by said issuance means. 

24. The system according to claim 23, wherein flow control relating to the data transfer is reversed by the command. 

25. The system according to claim 23, wherein a direction of transfer between said first and second devices when 
transferring commands and responses is reversed by the command. 

35 26. The system according to claim 23, wherein a direction of the data transfer between said first and second devices 
is reversed by the command. 

27 The system according to claim 23, wherein the data transfer is performed by sending data of an amount based on 
buffer information relating to a reception buffer obtained by bi-directional communication between sa.d first and 

AO second devices. 

28 A data transmission method for a data transmission system which transfers data between devices connected by 
a serial bus the data transler, started by first and second devices, performed on the basis of device information 
of the first and second devices provided in advance, wherein, in a case where the second device has not a flow 

as control function, a direction of the data transfer is reversed by a command issued by the first device, wherein the 

data is transferred the second device lo the first device after the direction is reversed. 

29 The method according to claim 28, wherein the data transfer is performed by sending data of an amount based 
on buffer information relating to a reception buffer obtained by bi-directional communication between said first and 

so second devices. 

30. The method according to claim 28, wherein the serial bus is a bus adapted to or based on the I EEE 1 394 standards. 

31. The method according to claim 28, wherein the serial bus is a bus adapted to or based on Universal Serial Bus 
55 standards. 

32. The method according to claim 26. wherein said first device provides image data. 
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33. The method according to claim 28. wherein said first device has a function to form a visible image based on image 
. data on a print medium and a lunction to read an original image, and selects one ol these lunclions. 

34. The method according to claim 28, wherein said second device processes received data. 

35. The method according to claim 28, wherein said second device is a host computer. 

36. The method according to claim 28, wherein the direction of the data transfer is changed to from the first device to 
the second device by another command issued by the first device. 

37. An image processing apparatus, comprising: 

communication means for performing communication with a target device by the datatransfer method in claim 
28; and 

reception means lor receiving image data from said target device via said communication means. 

38. An image processing apparatus, comprising: 

communication means for performing communication with a host device by the data transfer method in claim 
20 28; and 

providing means for providing image data to said host device via said communication means. 

39. A data transmission apparatus^connected to a serial bus, said apparatus comprising: 

25 transmission means for transmitting a command wh ich notifies reversing a direction of data transfer, to a device 

connected to the serial bus; and 

reception means for receiving the data alter the command has been transmitted. 

40. The apparatus according to claim 39, wherein the data transfer is performed by sending data of an amount based 
30 on buffer information relating to a reception buffer obtained by asynchronous bi-directional communication with 

said device, 

41. The apparatus according to the claim 39, wherein the direction of the data transfer is changed to from the first 
device to the second device by another command issued by the first device. 

35 

42. The apparatus according to claim 39, wherein the data transfer is performed by sending data of an amount based 
on bufler information relating to a reception buffer obtained by asynchronous bi-directional communication with 
said device. 
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